For which annotation properties can we leave objects dangling?

[cmungall]

Consider an ontology X with triples such as the following:

1. X:1 rdfs:subClassOf Y:2
2. X:1 rdfs:seeAlso A:3
3. X:2 owl:deprecated true
4. X:2 oio:consider B:4
5. X:3 rdfs:subClassOf SomeValuesFrom R:1 Z:5
6. X:4 skos:exactMatch D:6
7. X:5 RO:never-in-taxon NCBITaxon:7227. (shortcut encoding of a logical axiom)
8. X:5 RO:spatially-disjoint-with E:7
9. X:6 rdf:type F:8

in each case the object in the triple is an rdf resource that is not managed by X

What are the rules guiding what should be said about these object IRIs in various release artefacts?

We have a lot of tacit knowledge that we are starting to do a better job with but I think there are still many questions

some things are clear - e.g. in a base module we would not say anything about these

also: "dangling classes" (see OBO spec) are bad, break tools like pronto, yet we still have many of them

in other cases, we may want to extract a part of the relevant resource and include in an import module, but when? For all logical axioms (what about the shortcuts?)? For all owl classes? For OBO ontologies only?

What about cases where the object IRI is opaque, not OBO, but could have potentially useful information for a human - e.g a PMID - what axioms do we bring in?

IMO a nice clear mechanism for indicating that the object is not part of the domain of discourse and is just there for humans is to use a literal -- including xsd:anyURI. Bur regardless of that we should have clear consistent rules about where and when to traverse object IRIs.

[matentzn]

IMO a nice clear mechanism for indicating that the object is not part of the domain of discourse and is just there for humans is to use a literal -- including xsd:anyURI. Bur regardless of that we should have clear consistent rules about where and when to traverse object IRIs.

But it means that if we merge an OBO ontology into a wikidata extract, that the notes will remain unconnected..

I agree with general ticket though!