- 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
ISO 15926 in OWL: the RDS/WIP Variant
There are any number of different ways of mapping ISO 15926 into OWL. Its not a perfect fit, so at some point compromises need to be made. Compromises can be made for reasoning, validation, performance or security, for example. This page is intended to document options and discuss proposals for a variant to act as the primary publishing medium of the RDS/WIP
There is an associated project plan page detailing the milestones, dependencies and resourcing required to come to a conclusion on this issue.
Position statements from interested individuals/companies.
See the ISO 15926 Part 7 Use Case 1 for background on my position.
The form of OWL that the RDS/WIP takes needs to be the same as the form that software vendors choose for data exchange. It should be possible to validate the form of exchange data, but it does not need to be able to validate models, since it is assumed that these are validated elsewhere.
The representation should express as much ISO 15926 as possible in OWL. OWL has limitations in this regard, but we should do everything we can to make as much of the information accessible to a pure OWL/RDF application that knows nothing about ISO 15926.
SPARQL queries need to be able to perform well against data in this form in a secure way. That is to say, it is necessary that some data be visible to only selected security principals, and not impact the performance of the system (especially for highly restricted users such as public access). Moreover, this means that any literal present in the system must not be visible to a user unless that user can view relationships that address that literal.
Johan W. Klüwer
The basic representation of ISO 15926 reference data in the RDS/WIP should be complete with regard to what can be expressed using ISO 15926 Part 2 constructs. It should also be restricted to Part 2, to not contain expressions that are not sanctioned by the standard. These criteria are covered by the representation in (a subset of) OWL DL described at ISO15926inOWL. Reference data in this format can be checked for conformance to Part 2 by means of standard DL inference procedures. The format is also suitable as a sublanguage of that in which Part 7 templates are defined (see diagram on SigMmt#Templatedevelopment).
Derived representations of reference data, expressed using current W3C standards, must be provided for use in applications. Reference data in Part 2 constructs that have RDF/OWL native counterparts need to be accessible in their RDF/OWL native form (including Specialization as RDFS subclass, ClassOfRelationship as object property expressions, etc.). This needs to be developed incrementally, with the aim of eventually covering the full scope of the intended meaning of Part 2.
Applications will have varying requirements on the complexity of representation. The RDS/WIP should therefore provide several derived views of the same data.
Facts expressed in Part 7 template expressions should be allowed to exist in the RDS/WIP even when the corresponding facts in the basic Part 2 format do not. However, mechanisms then need to be in place to discover inconsistencies between Part 7 and Part 2/Part 4 expressions.
- How to represent ISO 15926 part 2 style literals - do we require their representation as a template-like object, or do we use native OWL? If using native OWL, literals can never be subjects. If using templates there are performance, security and distribution interoperability problems.
- Its seems possible to borrow the template to express specialization in the part 2 OWL/RDF form, while at the same time using rdfs:isSubclassOf to express the specialization in more natural OWL terms. This looks like it can be done by reifying the rdfs:isSubclassOf relationship in RDF, and providing it with the same identifier as that used for the specialization template instance (discussion thread to be attached).