Schema does not clearly prescribe how to interpret SSSOM in OWL

[matentzn]

          Another under-specified behaviour:

When serialising in OWL, sssom-py renders mappings that use a skos:(exact|narrow|broad|related|close)Match predicate as if the predicate was an annotation property. This is in agreement with how SEMAPV (re-)defines them.

But it is not obvious that those predicates should be treated as annotation properties. The OWL API for example considers that they are object properties, which is in agreement with how the SKOS specification explicitly defines them (“skos:mappingRelation, skos:closeMatch, skos:exactMatch, skos:broadMatch, skos:narrowMatch and skos:relatedMatch are each instances of owl:ObjectProperty”).

How the SKOS mapping properties are treated (as AP or as OP) matters very much in the context of SSSOM, since it decides how the mappings are translated into OWL axioms when serialising into OWL.

If the behaviour of sssom-py and of SEMAPV (treating the skos mapping properties as if they were annotation properties) is the intended one, then it should be explicitly stated in the specification:

For the purpose of serialising mappings into reified OWL axioms, mapping predicates from the http://www.w3.org/2004/02/skos/core# namespace MUST be considered to be OWL annotation properties, notwithstanding section 10.3 of the SKOS reference document.

Or, to allow for more instances of similar “reuse existing properties while changing their definition” behaviours beyond the case of SKOS:

For the purpose of serialising mappings into reified OWL axioms, mapping predicates that are present in the Semantic Mapping Vocabulary MUST be considered to be of the type defined in that vocabulary, even if the predicates are originally defined in another specification with a different type.

Originally posted by @gouttegd in #283 (comment)

[gouttegd]

I don’t see how this is a schema issue. The schema says the predicate ID must be a EntityReference. This is a large range, but this is needed if you want to allow various types of mapping predicates.

If you were to restrict that range to, say, OWL annotation properties, that would forbid using, for example, rdfs:subClassOf or owl:equivalentClass, which are explicitly listed as possible (encouraged, even!) mapping predicates.

And this would even forbid the use of skos:exactMatch (and other SKOS predicates), since they are, according to the original SKOS specification, object properties.

You seem to be looking for a way for the schema to say something like this: ”this slot accepts entity references of any kind but some entity references should be treated as being of a specific kind”. I don’t think the schema is the place to do this.

[matentzn]

You may or may not be right - I don't know. The problem is that LinkML schemas do not only play the role as schemas, but also as bridges to various other schema languages - so in this case, a piece of information is missing that allows me to interpret a LinkML schema in a completely different schema language (OWL).. basically yes, I am asking if there is something like a "slot_type" thing that makes sense in this scenario.

The other alternative is to do what we do right now: define a translation function that takes as an input an SSSOM dump in RDF and transforms it to owl based on custom rules. But this is very hacky, because you cant "guess" all possible mapping predicates, and if they are or should not be expressed as existential restrictions..