Open hlapp opened 5 years ago
+1 to @hlapp's comments
Also I've always disliked the IAO label as it is explicit not an import in the OWL sense.
Who could look into this?
+1 here from me as well.
I would like to officially propose:
owl:Entity
(or even rdf:resource) - we can use it to mean a class, property, or even an annotation assertion or logical axiom.EDIT: I am moving the following items to another ticket: https://github.com/information-artifact-ontology/ontology-metadata/issues/71
- 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.- 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.
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
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.
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.
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.
cc @dosumis @hkir-dev
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
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.
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:
These are the facts:
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 version information adds clutter to our ontologies.
: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.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.
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.
"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.
Not a lot of voting happening here...
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
saysIt is also a subproperty of
rdfs:seeAlso
, which arguably makes a lot of sense.The definition of IAO:'imported from' says
It is not asserted as a subproperty of either
rdfs:isDefinedBy
orrdfs: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.