Add property that is a weaker form of owl:imports for specifying dependencies

[cmungall]

Currently the OWL spec provides only one way of specifying dependencies, owl:imports

• most toolchains ALWAYS follow the import which usually involves a download
• there is no equivalent of modern package management systems that allow us to say "compatible with versions X to Y"

OBO ontologies are modular, and ontologies are frequently composed from other ontologies.

1. To avoid large products some kind of extraction or mireot or subgraph operation takes place (see extract in obook)
2. imports are frequently merged in (see Full products) for the release version

But regardless of whether steps 1 or 2 are followed, imports (merged or unmerged) cause many pain points

• the vast majority of users are frequently confused by seeing non-native terms when browsing terms for an ontology (this is why go.owl does not include the most powerful axioms)
• even the developers of ontology portals are confused by variation seen in OBOs (cc @graybeal)
• there is a well known problem of superimposition of different versions of non-native ontologies when natives with imports are merged (needing a so-called Unmireot step)

The solution to this is to release base files. These contain only native axioms.

A base file may contain dangling axioms. These could be everything from:

• logical definition axioms that reference another ontology
• dcterms:contribution axioms that reference non-OBO URIs like wikidata or orcid

This is a feature. Consumers can choose the strategy for resolving these, which could be anything from at the time of building an application ontology to UI time.

The one thing missing from this strategy is a way for the base file to declare dependencies. This should not be done using owl:imports, as it leads to all of the above issues.

There may be an existing property on the semweb we can use here, or we may need to mint one.

1. The dependency MUST specify the logical name of the depended on resource
   • example: uberon depends-on cl, go, cob, ...
   • This MAY be an OBO ontology, but it does not have to be
   • This MAY be something that has an OWL file, but it does not need to be. E.g. orcids, pmids, wikidata URIs
2. The dependency MAY specify tractable chunks of OWL that can be resolved over the wire that contain more information on the referenced entities
   • E.g. this may be something similar to the existing artefacts like cl/imports/uberon_import.owl
   • It may be special purpose extracts, e.g. https://github.com/cthoyt/wikidata-orcid-ontology/
   • clients MAY choose to utilize this, or they may choose to resolve dangling entities in their own way
3. the dependency MAY specify version requirements using a scheme taken from modern package management systems
   • this MAY use semver or it MAY use OBO date-style versionIRIs
   • this client may use this to reason over compatible versions
4. the dependency MAY specify which entities it expects to receive from the external source
   • this can be used to prevent injection attacks
   • this is analogous to the feature in most languages import FUNC_NAME1, ... from LIBRARY
   • the system MAY support ID expression features (e.g. import CL:* from cl)
   • this SHOULD be consistent with rdfs:isDefinedBy; e.g if I say import CL:1 from uberon, and somewhere else CL:1 says it is defined by CL, this is an error in my import statement

This is something to be progressed incrementally - starting with a simple property that can link an ontology to a logical name would be a good start, so long as we design it for future proofing

See https://ebooks.iospress.nl/volumearticle/60717 for a review of what exists currently

[matentzn]

I like it. The first stage of the rollout (OMO:dependsOn plus resource id) could be done outside of the constraints of community standardisation, to develop a well rounded proposal that works for us?