- 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 1.0 Plan Page
Release date: 2008-06-27
Completed as described on: 2008-10-14
Components (with responsible party listed in parentheses):
- Dedicated Host: Debian 4.0+, 1GB RAM, 40GB free disk after OS, SSH and root access (PCA)
- Server security provision (NRX)
- Install Java, Joseki, mysql (NRX)
- Provide SOAP functionality to Joseki (NRX)
- Configure endpoints (NRX)
- Document endpoint upload procedures (NRX)
- Convert Brutus to OWL/RDF (DNV/PCA)
- Upload OWL/RDF to endpoints (DNV/PCA)
- SPARQL to datasheet source XML (NRX)
- Framework for wrapping presentation XSL (NRX)
- Document datasheet presentation update process (NRX)
- Datasheet presentation XSL (DNV)
- Endpoint domain name mapping from rdlfacade.org (PCA)
- Testing (Bentley)
- Fix up all of the web site links to RDS/WIP browser functionality to point to the new service.
Migration to Joseki
For performance reasons, there's a lot of value to be gained in moving from PHP/RAP to Joseki. This may require moving the responsibility of supporting the service from DNV to POSC Caesar. DNV personnel would still operate the service, but an external hosting company may be used to provide the machine and the network connectivity.
Moving from the existing Tarcus implementation would require re-implementing the viewing capabilities. There is a need for some enhancement of these in any case.
The initial implementation of the viewer feature might not include the scalability features - scalability features will very likely be deferred to RDS/WIP 2.0.
Presentation will be via XSL, leveraging some existing technology. The source form for the XSL is an XML representation of a concept as a sort of "datasheet". IRM define the input schema and provide the XSL. NRX will provide the SPARQL and underlying XSL to generate the input data to the IRM XSL format. The presentations will be done in real time against the triplestore via the framework produced by NRX with Joseki. Presentation of a ISO 15926 concept in the RDS/WIP will be a series of steps executed as a streaming pipeline:
- The base URI of the concept is the only input.
- SPARQL extracts data from triple store for that URI and outputs as SPARQL result sets XML
- pre-processing XSLs transform SPARQL result sets into a single input schema XML.
NRX will look after the whole presentation pipeline. DNV will provide the presentation XSL. NRX will provide and document a means by which IRM staff can effect changes to the presentation XSL and perhaps even extend the SPARQL and pre-processing XSLs.
Content updates will be initially supported via the Brutus system, but since IRM personnel will be responsible for all updates, they may choose to do them in any way they see fit. Updates to the endpoints will be via OWL/RDF files. The update process will be built and documented by NRX.
Would be good if Bentley could test the completed service.