search

iofoundry / ontology

MIT License
42 stars 12 forks source link

Use of owl:equivalentProperty for owl:AnnotationProperties #42

Closed mereolog closed 9 months ago

mereolog commented 1 year ago

MappingAnnotationVocabularyToCommons.rdf uses owl:equivalentProperty to express the fact that two annotation properties are equivalent, e.g., https://github.com/iofoundry/ontology/blob/fed12c3abd8eac4fc3a7007f20a36e95678a0dec/core/commonstocoremapping/meta/MappingAnnotationVocabularyToCommons.rdf#L61-L63 As far as I can tell, the OWL spec does not allow for such axioms, see: https://www.w3.org/TR/owl2-syntax/#Annotation_Axioms.

In any case Protege complains about them when it tries to load them:

INFO 08:27:45 Unparsed triple: https://spec.industrialontologies.org/ontology/core/meta/AnnotationVocabulary/explanatoryNote -> http://www.w3.org/2002/07/owl#equivalentProperty -> https://www.omg.org/spec/Commons/AnnotationVocabulary/explanatoryNote

ekwallace commented 1 year ago

I had a look at the relevant parts of the OWL 2 syntax document, and I agree that it looks like it doesn't support using equivalentProperty in axioms concerning annotations. In fact, it doesn't look like it supports direct use of equivalentProperty at all (only its subproperties) in the DL interpretation of OWL (aka the Direct Semantics). Not sure what the OWL 2 RDF mapping and RDF semantics say about this, but it does seem likely that OWL DL oriented tools will complain about using equivalentProperty in this way. Does anyone have contrary experience (where tools do support using equivalentProperty statements about annotation properties?

ElisaKendall commented 1 year ago

Equivalent properties may only be available in OWL DL for object and data properties, where you have:

Having said this, the mapping to RDF syntax doesn't prevent it, though it might be idiomatic. Very few statements about annotation properties are allowed in OWL DL, including the property hierarchies we have in the annotation vocabulary. Protege is more lenient about those for some reason. If we restrict the usage to mappings, especially if some property is being deprecated and replaced with another (e.g., renamed), using such a statement at least connects the dots from the old property to the new one. Perhaps we should add an explanatory note when we do something like this, though, and state that the pattern is (1) idiomatic, and (2) used either in mappings or in cases where a property has been deprecated to point to the successor, if there is one.