Changes between Version 2 and Version 3 of RdsWipUseCaseDiscreteEditing

Timestamp:

06/10/08 09:15:41 (16 years ago)

Author:

jbourne (IP: 69.156.12.76)

Comment:

--

RdsWipUseCaseDiscreteEditing

@@ -1 +1 @@
 = RDS/WIP Use Case: Discrete Editing =
 
-A description of the use that backs up the requirement for discrete editing - distilled from a phone conversation between Julian Bourne (NRX) and Robin Benjamins (Bechtel) 2008-06-10.
+A description of the use case that backs up the requirement for discrete editing - distilled from a phone conversation between Julian Bourne (NRX) and Robin Benjamins (Bechtel) 2008-06-10.
 
 == Overview ==
@@ -15 +15 @@
 For that reason, they see no requirement for bulk upload as they are not anticipating loading their existing classes into the RDS/WIP in either raw RDF, shortcut template or ISO 15926 forms.
 
-Moreover, they feel that designing directly in ISO 15926 will be appropriate and beneficial in that they have the domain expertise to create those classes directly in ISO 15926 without the need for an interim description or harmonization done collaboratively in public.
+Moreover, they feel that designing directly in ISO 15926 will be appropriate and beneficial in that they have the domain expertise to create those classes directly in the RDS/WIP without the need for preceding public collaboration.
 
 == Process ==
 
-The editing process should be close to that provided by the existing SQL Server/.NET implementation.
+The editing process should be close to that provided by the existing SQL Server/.NET implementation in terms of features.
 
 == Implementation Limitations ==
 
-From an implementation point of view, submission would still be via the bulk upload processes.  The reason for this is so that the administrative @todo
+From an implementation point of view, submission would still be via the bulk upload processes.  The reason for this is so that the administrative functionality applies equally well to bulk upload and discretely edited material.  Secondly, it allows discretely edited material to be examined in full prior to submission.  It would also allow "delete" functionality prior to submission.
 
-== Other Considerations ==
+As a side note: delete functionality will not be allowed for published material, except by the site moderators: deprecation will be provided as an alternative mechanism.  Theoretically, it should be possibly for anyone to deprecate anyone else's work, but note that moderators may easily undo a deprecation under the existing RDS/WIP 2.0 administration proposals.
 
-Bechtel's investment in the SQL Server/.NET Tarcus implementation for RDS/WIP 1.0 provided @todo
+Naturally, the implementation as described could quite easily be supported with a remote client, or with a remote service providing thin-client functionality, however, there is some perceived benefit in terms of lowering access barriers by providing a thin-client solution on the actual RDS/WIP server.
+
+== Dependencies ==
+
+This implementation is completely dependent on:
+
+ * Stable base templates for ISO 15926.
+ * Stable OWL/RDF for ISO 15926.
+ * Administrative controls on the RDS/WIP.
+ * Bulk submission service for RDS/WIP.
+ * Consistent domain naming for the RDS/WIP endpoints.
+
+== Interim Solution ==
+
+Since Bechtel run an internal version of Tarcus and the RDS Browser/Editor, they can use that for editing in the short term, until the RDS/WIP 2.0 discrete editing piece is complete.
+
+I (Julian Bourne) undertake to adapt the RDS2RDF program to generate correct OWL/RDF for bulk upload into the RDS/WIP at the time the discrete editing feature becomes available, so as to enable Bechtel to transition seamlessly to the RDS/WIP 2.0.  It will be up to Bechtel, however, to load/add necessary base templates into their version of Tarcus if they require them to perform their work.
+