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.

Overview

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.

Background

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.

Process

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 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.

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.

Home
About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std
Projects
Search