Skip to content

PODD Redesign Specification

Jump to bottom
ansell edited this page Oct 31, 2012 · 2 revisions

PODD Redesign Specification

Definitions

  • Schema Ontologies : The schemas that define valid structures for PODD Artifacts. These are represented using OWL2 Ontologies that must be valid in at least the OWL2-DL Profile and not raise validation errors when validated using OWLDL compatible OWLAPI OWLReasoners.
  • PODD Artifacts : The data objects that are stored in the PODD system. These are represented using OWL2 Ontologies that must be valid in at least the OWL2-DL Profile and not raise validation errors when validated using OWLDL compatible OWLAPI OWLReasoners.
  • PODD Top Concept : Types of information that can be stored as standalone PODD Artifacts. These must be defined in a Schema Ontology that is linked to from PODD Artifacts that are instances of PODD Top Concepts.
  • PODD Concept : Types of information that must be stored inside of PODD Artifacts that have a principal type of PODD Top Concept. The top of the tree
  • PODD Contains Properties : Subproperties of PODD:Contains must only be used to derive a continuous single chain from the single PODD Top Concept instance in each PODD Artifact to the object of the PODD Contains Property statement.
  • PODD RefersTo Properties : Subproperties of PODD:RefersTo must only be used to link to another instance of a PODD Concept using the correct range and domain as declared by the property.
  • PODD Artifact Link Properties : Subproperties of RDFS:seeAlso, to indicate that the linked object is related to the subject, where the subject and object are both part of PODD Artifacts.
  • Edit Conflict : When multiple users, or a single user with multiple web browser pages, attempt to update a PODD Artifact concurrently and the edits are not able to be automatically merged.

Core design

PODD is designed around the use of Schema Ontologies to validate PODD Artifacts that would be difficult to work with in a SQL based system due to the range of information that each artifact may or may not contain. In the context of the PODD Redesign Project, PODD Artifacts are generally scientific experiment data, but they could include any data.

PODD Artifacts are validated using specific versions of the Schema Ontologies. This allows PODD to support new versions of Schema Ontologies while retaining complete compatibility with past PODD Artifacts by validating them using the previous Schema Ontologies.

The initial PODD project was a theoretically successful implementation based on this design, however, the implemented system could not be used in practice due to scaling issues that were displayed with very small PODD Artifacts. The initial PODD project attempted a very aggressive versioning strategy based on an hypothetical method for splitting PODD Artifacts up into smaller objects, and versioning each object individually. Although in theory this may have seemed like a performance benefit, the cost of loading and validating many small objects, while tracking their previous versions inividually, was a severe performance penalty that caused the project to be a complete failure in practice. In addition, it also attempted to split up Schema Ontologies into component parts, which caused a massive slowdown when attempting to validate quite simple object structures if the ontology was fairly complex, as each part of the ontology was loaded separately.

Modifications

The PODD Redesign Project aims to make some minor modifications to the initial PODD project implementation, which requires a reimplementation from scratch.

The substantial changes are to:

  • Avoid the use of sub-artifact objects and instead always deal with PODD Artifacts.
  • PODD Artifacts cannot be modified after they are published, but they can be forked with a new identifier along with the existing data and permissions into new PODD Artifacts.
  • Track Schema Ontology versions at the level of Ontology rather than at the axiom/property/class level as the original PODD system attempted to do.
  • The web application must be lightweight : It must not rely on a specific datastore implementation. This is possible using OWLAPI and Sesame, but not using Fedora as it has a unique method for storage, including different rules based on the content of a document, where other systems are able to cope with arbitrary data.

These modifications to the original design will enable the PODD Redesign Project to test out a more conventional system that may scale better with both memory size and CPU capacity. In comparison to the original design, the modifications enable the system to cache the entirety of objects at different levels, including in memory and in databases, without having to cache and validate past versions of the object

Some versioning of PODD Artifacts may be necessary to enable web users to edit different versions concurrently and possibly avoid Edit Conflicts. However, these versions do not need to be persistent, as they only apply to short term sessions, and after publication a new identifier is created instead of just assigning a new version to the PODD Artifact.

Once a PODD Artifact is published, a new PODD Artifact must be created internally based on the content and roles assigned to the old PODD Artifact in order to make further changes. The new PODD Artifact may have a link back to the published PODD Artifact, but it will have a new permanent identifier so that it can be distinguished uniquely in future. The basic rationale for this is that the PODD Artifact must be published in the PODD system before it can be cited. Once it is cited, the data that the citation points to must remain constant for a period of time.

Proposed New Features (All time depending)

  1. Administrator uploaded ontologies : The original PODD system required the current Schema Ontologies to be distributed with the package and they could not be modified once the system was running. The redesigned PODD system will allow administrators to temporarily put the web application into maintenance mode to modify ontologies. The maintenance mode will allow batch migration of objects from old Schema Ontologies to new versions, as long as there are no validation failures. Any failures with validation will require manual SPARQL scripts to be run to update the database, while in administration mode.
  2. Arbitrary PODD Top Concepts : The redesigned PODD system must allow for arbitrary Top Concepts, although only PODD Projects will be implemented in the HTML user interface.
  3. Links between PODD Artifacts : The design constraint here is that the PODD Artifact being linked to must be published, although it may not be publically available. This is to ensure that the reference will be stable, and if changes are required to the linked PODD Artifact a new permanent identifier will be used which will not clash with the current permanent identifier. Any changes to the PODD Artifact would require a new permanent identifier, which would not change the meaning of the current identifier.

Clone this wiki locally