- RDS/WIP Introduction
- RDS/WIP Sample Queries
- RDS/WIP Staging Diagrams
- RDS/WIP 1.0 Plan
- RDS/WIP 1.0 Testing
- RDS/WIP 1.0 Process
- RDS/WIP 1.0 Inventory
- RDS/WIP 2.0 Plan
- RDS/WIP ID Generator
- RDS/WIP Domain Proposal
- RDS/WIP Requirements Table
- RDS/WIP Use Case: Discrete Editing
- RDS/WIP Use Case: CSV Upload
- RDS/WIP 1.0 General Use Cases
- RDS/WIP 2.0 General Use Cases
- RDS/WIP ISO 15926 Template Definitions
- RDS/WIP OWL/RDF Definition
- RDS/WIP OWL/RDF Project Plan
- RDS/WIP Forums
- RDS/WIP Use Case: Bulk Upload
RDS/WIP Use Case: Discrete Editing
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.
Discrete editing is a term we use in contrast to bulk editing. It means being able to edit the RDS/WIP interactively on the actual RDS/WIP server.
The need for this is seen to stem from EPCs who wish to have a one-stop-shop for editing into the RDS/WIP built around thin-client principles with a high degree of accessibility.
Current Bechtel practice is to maintain an internal class library consisting of some 50 classes and 2000 properties. They would prefer that the class library is discarded and rebuilt from scratch in ISO 15926, since it is currently fairly flat in structure.
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 the RDS/WIP without the need for preceding public collaboration.
The editing process should be close to that provided by the existing SQL Server/.NET implementation in terms of features.
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.
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.
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.
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.
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.