Principle 1 (fp-open) requests using IAO:'imported from' for linking back

[hlapp]

Is there a good reason this shouldn't simply be rdfs:isDefinedBy, or at least allow that to comply with the requirement?

The definition for rdfs:isDefinedBy says

rdfs:isDefinedBy is an instance of rdf:Property that is used to indicate a resource defining the subject resource. This property may be used to indicate an RDF vocabulary in which a resource is described.

It is also a subproperty of rdfs:seeAlso, which arguably makes a lot of sense.

The definition of IAO:'imported from' says

For external terms/classes, the ontology from which the term was imported.

It is not asserted as a subproperty of either rdfs:isDefinedBy or rdfs:seeAlso.

It seems silly to not allow one as much as the other for achieving compliance?

My concern here is machine-interoperability in a world where ontologies get increasingly reused through mixing and matching. If there's a universally used property that seems suitable for asking that machines recognize it as indicating from where a term originally comes in a store synthesized from many sources, then I think the OBO principles should at least mention and allow use of that property, if not encourage it.

[cmungall]

+1 to @hlapp's comments

Also I've always disliked the IAO label as it is explicit not an import in the OWL sense.

[nlharris]

Who could look into this?

[matentzn]

+1 here from me as well.

[matentzn]

I would like to officially propose:

1. Use rdfs:isDefinedBy to denote the home ontology of a term OR axiom. Across all of OBO.
2. The domain of rdfs:isDefinedBy is owl:Entity (or even rdf:resource) - we can use it to mean a class, property, or even an annotation assertion or logical axiom.
3. The range of rdfs:isDefinedBy must be the PURL (e.g. http://purl.obolibrary.org/obo/mondo.owl) of the respective ontology in question.

EDIT: I am moving the following items to another ticket: https://github.com/information-artifact-ontology/ontology-metadata/issues/71

4. We use owl:versionInfo to indicate where a statement (logical axiom or annotation assertion comes from). I propose here that this should be the full ontology version IRI.
5. I am a bit against using owl:VersionInfo on term level, because the terms themselves are eternal (the IDs I mean). The statements about the terms are transitory and need to be versioned.

[cmungall]

For 4 are you. proposing e.g

go:1234 owl:versionInfo <http:...>

Are we sure this won't cause issues with tools that expect it to be used with an ontology? Although use for any construct is permitted https://www.w3.org/TR/owl-ref/#versionInfo-def

Also isn't a bit odd that we use versionInfo with a range of string at the ontology level but a URI when annotating an entity or axiom? Not inherently wrong but potentially confusing

I think 1-3 are totally uncontroversial and we should proceed with

versioning is a bit trickier especially if we want to encourage consistent usage. Maybe this could be a separate proposal in the interest of moving forward with the core proposal

[matentzn]

I think versionInfo is appropriate in this case, and I am not too worried about this being the wrong or write property - I would just to start collecting this information yesterday, and if we want to change it to something else, we can.. For now, I would like to insist on all 5 points, and only worry about veto's. @cmungall do you feel like there would be a danger in introducing this vocabulary? I would like to roll it out asap :D

I also would like @jamesaoverton to weigh in on this.

[graybeal]

I'm wondering if items 4 & 5 should be a separate ticket?

I love the simplicity of definedBy, and hate to bring up any potential concern. But will this be a conflict if some people use definedBy to indicate where an entity is more fully described, like a home page? This would perhaps only be the case for non-semantic web resources, e.g., a policy statement, so maybe there is no conflict.

[matentzn]

Thank you @graybeal No one I know is really using any of these consistently, but I would prefer using standard vocabulary over the concern of someone using it somehow differently.. Tools need to check the range of the annotation anyways to decide what to do with it. But I take your point.

Also, since you are the second asking for 4+5 to be a sep. ticket, I will oblige.

[matentzn]

cc @dosumis @hkir-dev

[matentzn]

There you go: https://github.com/information-artifact-ontology/ontology-metadata/issues/71

[matentzn]

Ok, since no one like my idea of using owl:versionInfo, and I need to be able to trace an axiom to a specific version of an ontology it's coming from, please indicate here wether you would be willing to accept that rdfs:isdefinedBy should be used in conjunction with a version IRI Instead of a base PURL. 👍 for those in favour 👎 against (and argument). Thank you :)

Cc @jonquet @jamesaoverton

[dosumis]

rdfs:isdefinedBy should be used in conjunction with a version IRI Instead of a base PURL

STRONGLY AGREE. Any other option is too complex for tracking down term as defined at the time of release.

[matentzn]

Alright for readers of this thread and others, lets restart the conversation.

We are trying two fundamental things here, and as far as I understand we are agreed on that:

1. Providing a mechanism by which we can track a single axiom (:A rdfs:subClassOf :B) or annotation (:A rdfs:label "A Label") to some ontology. Use cases include: My ontology is inconsistent, where did that axiom come from? Or: Why do I have three definitions on the same term? Did some ontology add a new definition without notifying the ontology the term comes from"? Knowledge Graphs should also be able to track provenance under merge and point users back to the source of an "edge".
2. The debate is fundamentally about whether or not the source is an ontology (GO, UBERON, RO, OBI) or a version of an ontology (GO from 2021-08-10).

These are the facts:

• There are a few STRONG opinions on how things should GO that contradict each other: @dosumis for example wants to use versionIRIs ("STRONGLY AGREE"), while @cmungall believes they will create "a nightmare, we’ll have to do string parsing. Strong against".
• There have been strong sentiments against other forms of additional axioms like using an additional owl:versionInfo annotation alongside an rdfs:isDefinedBy.

The way I see it, before we do anything else, we need to come to an agreement of whether adding versioning information to axioms is fundamentally a bad idea. We do know why its a good idea (we can accurately trace a statement to the source and then decide things like: "we simply need to update the import", or "this. isin the latest release, we should make a ticket".) Here is the main arguments against versioning (for full disclosure, I am in the pro versioning camp):

Adding axiom version information introduces clutter.

Adding version information adds clutter to our ontologies.

• Version IRIs maybe almost ok, but queries will go from: :A rdfs:isDefinedBy <http://purl.obolibrary.org/obo/mondo.owl> to :A rdfs:isDefinedBy ?source . FILTER(STARTSWITH(str(?source),"http://purl.obolibrary.org/obo/mondo")) if we use version IRIs.
• owl:versionInfo add a lot of axiom annotations, which add to file size etc etc

As an aside, there are also various OBO format incompatibilities. All our OBO format files will become a nightmare to look at until someone extends the spec to support rdfs:isDefinedBy - oio:source conversions or some such.

Versioning axioms is highly idiosyncratic

No one in the word, other than OBO, does that kind of thing. We should improve owl:imports or some other mechanism to compose our ontologies with axioms for upstream sources.

Axiom versions are redundant

"We can find the version from an axiom by simply looking at the version IRI of the source ontology". Named graphs would be a much terser way to version axioms. However: 1) owl does not know named graphs. 2) once you merge a bunch of ontologies together, you wont know which axiom came from where.

Here is the new vote:

👍 I think versioning axioms is a good idea. Lets discuss how to do it 👎 I think versioning axioms is fundamentally wrong for whatever reasons and we should find other ways to deal with the use cases.

[nlharris]

Not a lot of voting happening here...