Skip to content

Prototype steps

Jump to bottom
Peter Ansell edited this page Jan 22, 2014 · 3 revisions

First steps

The Web Service API to support the following activities must not change after the prototype is completed. This is to ensure that the basic method of putting data into the PODD system is stable and can be used immediately by users who abandoned the initial PODD system when it failed to support their use cases.

The prototype must be able to support the following sequence of activities:

  1. Load Schema Ontologies from a static source, infer all new axioms for each of the Schema Ontologies using an OWL reasoner, and then store both the concrete and inferred axioms in a SPARQL database in separate SPARQL Graphs so that they can be queried using SPARQL and they can be queried separately if necessary.
  2. Load the first PODD Artifact which references one of the Schema Ontologies. The link between the PODD Artifact and the Schema Ontology must be to a specific version URI. Links are not allowed directly to the version independent Schema Ontology URI after upload. In the uploaded RDF document the user may include the direct ontology URI to avoid having to know the version that is used by PODD, but PODD must convert the link to be to the most current version URI for the Schema Ontology.
  3. (Optional for the prototype) Put the application into maintenance mode to stop new PODD Artifacts being uploaded
  4. Load a new, incompatible version of a Schema Ontology and assign it a new version, and point the current version of the Schema Ontology to the new version URI.
  5. (Optional for the prototype) Take the application out of maintenance mode to allow new PODD Artifacts to be uploaded
  6. Load a second PODD Artifact which references the new version of the updated Schema Ontology
  7. Verify that the first PODD Artifact still references, and can be validated against, the first version of the Schema Ontology.

Second steps

Performance testing:

  • The performance of the system when uploading new PODD Artifacts must be satisfactory.
  • The performance of the system when updating existing PODD Artifacts which have not yet been published must be satisfactory.
  • The performance of the system when downloading the contents of existing PODD Artifacts must be satisfactory.

Third steps

The Web Service API for the following may change after the prototype is completed.

  • The prototype must be able to accept arbitrary file uploads to include as links inside of PODD Artifacts. This is necessary to enable binary data to be included in Artifacts without converting the data to RDF.
  • The prototype must have a basic security protocol to enable authentication to distinguish between unauthenticated users, authenticated users, and administrators. Administrators must be able to specify permissions for authenticated users to access and edit specific PODD Artifacts.

Clone this wiki locally