[[TracNav(TracNav/RdsWip)]] = 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 [wiki:RdsWipProject RDS/WIP] There is an associated [wiki:ISO15926inOWLforRDSWIPPlan project plan page] detailing the milestones, dependencies and resourcing required to come to a conclusion on this issue. == Position Statements == Position statements from interested individuals/companies. === Julian Bourne === See the [wiki:ISO15926Part7UseCase1 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 [wiki: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 MmtSig#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 [http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema/lexical/specialization.html Specialization] as RDFS [http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DefiningSimpleClasses subclass], [http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema/lexical/class_of_relationship.html ClassOfRelationship] as [http://www.w3.org/TR/2004/REC-owl-guide-20040210/#SimpleProperties 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. == Open Issues == * 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. == Closed Issues == * 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). [[ViewTopic(ISO15926inOWLforRDSWIP)]]