Version 10 (modified by jbourne, 16 years ago)

--

RDS/WIP Architecture

Diagrams for the general RDS/WIP architecture, including staging over time.

RDS/WIP Currently

In the current system, a high degree of risk and rigidity is involved due to the large number of data stores and transforms through which definitions must flow. The white boxes in the diagram below illustrate the transforms - essentially there are four transforms here, managed by three parties from different companies, countries and language backgrounds. Edited data enters the Brutus system, to be exported to Minus, then uploaded to Buffer, then transformed to Tarcus and then converted by RDS2RDF into the triplestore. This design results in very high maintenance costs, and very slow change turnaround.

RDS/WIP 1.0 System

When RDS/WIP 1.0 is introduced, it reduces the number of groups involved in information transform to just one: DNV's Information Risk Management (IRM) group. This group have undertaken to manage all edits to the data up until the 2.0 system is released.

In this release, a user can give data to the IRM group in OWL/RDF format to upload into the server. NRX will provide the base system implementation and XML presentation transforms, POSC Caesar will provide the hosting and DNV will provide the XHTML presentation transforms.

The subversion repository is used for storing the presentation transforms, and any other required data (such as images, CSS files and so on) required for displaying pages. Files specific to a single class or template presentation could be stored here.

RDS/WIP 2.0 System

The RDS/WIP 2.0 system removes the reliance on IRM's internal systems for editing the RDS/WIP. Users will be able to contribute in a number of different ways including initially bulk submissions, followed soon after by discrete editing. Of course, it supports everything from the 1.0 system as well.

Future

A great thing about this design is that the GraphViz? DOT and LaTex? xy-pic diagram generation demonstrated by DNV elsewhere on this site could be leveraged easily in this design in concert with some appropriate SPARQL code to assemble the source XML for ready use by XSLT in presentation.

Attachments

Home
About PCA
Reference Data Services
Projects
Workgroups