Provide a general mechanism for restricting the range of annotation properties

[cmungall]

We have many cases where people use APs differently w.r.t the broad datatype used, and the kind of filler

With OWL, it is perfectly valid to use the same AP but to have values range from

• literals
  • strings
  • language literals
  • xsd:anyURIs
• objects

This is clearly not desirable. We have situations now where we are using APs completely differently across ontologies. E.g. ENVO uses oio:inSubset with a range of language literal

Our options are:

• use OPs and DPs, but induce punning on the classes.
• pun on the APs themselves, and have a parallel OP or DP.
• write clear markdown documentation that people should follow
• write lots and lots of sparql queries in robot
• use a schema language
  • shex
  • shacl
  • linkml

These are not mutually incompatible. Some are inherently dangerous - e.g. pun on APs themselves. But note we are kind of doing this with skos (see skos ticket #65 )

[cmungall]

I'm trying to do a query on ontobee to determine the scope of the problem but it times out

using @jamesaoverton's rdftab.js it is easy to write queries like

SELECT
            DISTINCT s1.predicate AS subject
          FROM statements AS s1, statements AS s2 ON (s1.predicate=s2.predicate)
          WHERE s1.value IS NOT NULL and s2.object IS NOT NULL

on just one ontology (envo) we see many (but these often come from mixed styles in imports):

property	s1_datatype
rdfs:comment	xsd:string
dct:license
dce:creator
IAO:0000115
IAO:0000115	xsd:string
oio:hasDbXref	xsd:string
owl:annotatedTarget	xsd:string
rdfs:seeAlso
rdfs:comment
oio:created_by	xsd:string
IAO:0000117
IAO:0000119
owl:annotatedTarget
rdfs:seeAlso	xsd:anyURI
oio:inSubset
oio:hasDbXref
IAO:0100001	xsd:boolean
oio:consider
oio:consider	xsd:string
IAO:0100001	xsd:string
IAO:0100001
oio:created_by
rdfs:comment	xsd:boolean
dce:contributor
dce:creator	xsd:string
oio:hasDbXref	xsd:anyURI
IAO:0000119	xsd:anyURI
IAO:0000117	xsd:string
http://schema.org/image	xsd:anyURI
IAO:0100001	xsd:anyURI
oio:hasDbXref	rdfs:Literal

some of these are obviously valid - e.g. generic for owl reification

[matentzn]

Interesting! I would love some kind of solution in this space, but for some things like "seeAlso", which should clearly be an anyUri, forcing a range may be an uphill battle. You already made me abandon my hope for using orcids for created_by - which is also undeniably better than pg or cjm. Its seems odd that given the fact you can say:

<http://purl.obolibrary.org/obo/TEST_1> rdf:type owl:AnnotationProperty ;
                                            rdfs:range xsd:int .

<http://purl.obolibrary.org/obo/CL_0017537> rdf:type owl:Class ;
                                            <http://purl.obolibrary.org/obo/TEST_1> "String" .

There is nothing (I tried OWL profile validation) that will throw a warning..

[alanruttenberg]

See https://www.w3.org/TR/owl2-syntax/#Annotation_Axioms You can declare domain and range for annotation properties. However, annotations are considered nonlogical in the direct semantics, so a reasoner won't look at them, since a reasoner deals with the logical stuff only. If you want to validate you need an external mechanism. I've seen SHACL more than the other choices, but I haven't used any of them. When I've needed to check such things I've used SPARQL. Punning on property types is disallowed in OWL direct semantics.You probably wouldn't want to pun anyways because then the subject (e.g. a class) will also be considered an individual which may be confusing and may also impact reasoning performance. Why would you have to write lots and lots of sparql queries? The range can be picked up from the annotation property range and then used in the query in the rest of the query. FWIW in the RDF-based Semantics <https://www.w3.org/2007/OWL/wiki/RDF-Based_Semantics> annotation axioms such as domain and range do have force. "For *annotations properties* note that annotations are not "semantic-free" under the OWL 2 RDF-Based Semantics. Just like every other triple or set of triples occurring in an RDF graph, an annotation is assigned a truth value by any given OWL 2 RDF-Based interpretation. Hence, although annotations are meant to be "semantically weak", i.e., their formal meaning does not significantly exceed that originating from the RDF Semantics specification, adding an annotation may still change the meaning of an ontology."

…

On Tue, May 11, 2021 at 7:22 AM Nico Matentzoglu ***@***.***> wrote: Interesting! I would love some kind of solution in this space, but for some things like "seeAlso", which should clearly be an anyUri, forcing a range may be an uphill battle. You already made me abandon my hope for using orcids for created_by - which is also undeniably better than pg or cjm. Its seems odd that given the fact you can say: <http://purl.obolibrary.org/obo/TEST_1> rdf:type owl:AnnotationProperty ; rdfs:range xsd:int . <http://purl.obolibrary.org/obo/CL_0017537> rdf:type owl:Class ; <http://purl.obolibrary.org/obo/TEST_1> "String" . There is nothing (I tried OWL profile validation) that will throw a warning.. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3CDRSEEHJXZTLCFUHXL3TNEHOHANCNFSM44T6OVFQ> .

[cmungall]

Some updates on approaches in the last few years:

• @balhoff experimented with a SHACL approach here: https://github.com/balhoff/shacl-runner/blob/master/shapes.ttl
• OAK includes a proposed LinkML OMO schema, and has a validator https://incatools.github.io/ontology-access-kit/howtos/validate-an-obo-ontology.html

@alanruttenberg makes a good point that you can "axiomatize" APs to some extent, and this would eliminate the need for repetitive queries, there could just be a generic query. But this still wouldn't capture all constraints and more nuanced rules. In particular, many D/Rs are actually contextual.

Nevertheless whichever approach is taken in the long run it seems clear we should (a) add more D/R constraints onto APs in OMO (b) have a generic robot sparql rule that leverages these.