-
Notifications
You must be signed in to change notification settings - Fork 2
Requirements for HY_Features OWL encoding
This page is to address the emerging issues around publication of ontologies for HY_Features.
There are several possible scopes for OWL encodings:
- A canonical encoding providing a list of identifiers that may be recognised directly as HY_Features concepts (stable enough that for instance a client could recognise without further input that it can perform operations on data based on the HY_Features semantics.
- A HY_Features conformant ontology - i.e. a valid instance of the conformance target for the Conceptual Model
- A specific flavour of OWL (or RDFS) (see https://www.w3.org/TR/owl2-profiles/)
- an ontology conforming to a particular upper ontology and using concepts from a given domain (e.g. ISO19150 OWL encoding rules)
What scopes are required for ELFIE. Working presumption for OGC support (via Rob Atkinson in NextGEOSS project) is #1, however arguments could be made for other scopes.
The Canonical OWL encoding will form a part of the WaterML specification suite, and as such will need to conform to OGC Policies and Procedures, including OGC Naming Authority processes.
Identifiers should exist in a namespace that is governed by the OGC, and clearly identifiable as such, and supported by OGC URI resolution infrastructure.
HY_Features OWL encoding should be packaged to mirror the conformance Classes of HY_Features. These are the discrete Application Schema that make up HY_Features. This means that governance arrangements for individual specifications can be directly mirrored by ontology maintenance processes.
The OWL should be as simple as possible to use - perhaps OWL-RL profile, with all inferrable statements entailed so clients do no need to perform OWL reasoning in order to get relevant declarative statements about model elements. Datatypes should be direct RDF datatypes where relevant, rather than require use of equivalence or subclass axioms - for example ISO 19103 CharacterString datatype should be simply encoded as xsd:string type.
All model elements should be represented in the OWL ontology artefact (including any imported ontologies). Those elements should conform to the meaning of the specification.
Only model elements should be declared in the OWL ontology artefact (including any imported ontologies).
All model elements should be represented by RDF elements with the same localname, modulo token conversion rules required to meet RDF syntax requirement.
Model documentation should be provided as annotation using appropriate annotations properties. (rdfs:label, rdfs:comment, rdfs:isDefinedBy etc).
- schema.org domainIncludes
- skos:broader (rdfs:subClassOf is transitive and doesnt tell you the immediate parent class)
- skos:definition (
- skos:prefLabel
- skos:altLabel - for aliases
- where do OCL constraints
Mappings to specific implementations should be managed in separate artefacts, able to be managed by relevant stakeholders independently of the canonical
The process of deriving the OWL model should be reproducible, and expressed in automatable rules as far as possible. This is necessary: 1 To assist with updates 1 To ensure completeness and consistency 1 To allow support infrastructure to provide a predictable set of resolution services for all models using the same rules
i.e. it is a desired outcome that the methodology for publication of Conceptual Models and implementation artefacts be reusable, documented and sustainable.