search

information-artifact-ontology / ontology-metadata

OBO Metadata Ontology
Creative Commons Zero v1.0 Universal
19 stars 8 forks source link

Use owl:versionInfo for versioning of everything #71

Open matentzn opened 2 years ago

matentzn commented 2 years ago

As first described in this ticket: https://github.com/OBOFoundry/OBOFoundry.github.io/issues/806

I would like to propose the following:

  1. We should use owl:versionInfo for versioning annotation assertions and owl axioms, like:
###  http://w3id.org/obook/A
<http://w3id.org/obook/A> rdf:type owl:Class ;
                          rdfs:comment "Some comment" .

[ rdf:type owl:Axiom ;
   owl:annotatedSource <http://w3id.org/obook/A> ;
   owl:annotatedProperty rdfs:comment ;
   owl:annotatedTarget "Some comment" ;
   owl:versionInfo <http://purl.obolibrary.org/obo/cl/releases/2021-09-09/cl.owl>
 ] .

###  http://w3id.org/obook/B
<http://w3id.org/obook/B> rdf:type owl:Class ;
                          rdfs:subClassOf <http://w3id.org/obook/A> .

[ rdf:type owl:Axiom ;
   owl:annotatedSource <http://w3id.org/obook/B> ;
   owl:annotatedProperty rdfs:subClassOf ;
   owl:annotatedTarget <http://w3id.org/obook/A> ;
   owl:versionInfo <http://purl.obolibrary.org/obo/cl/releases/2021-09-09/cl.owl>
 ] .
  1. We should NOT use owl:versionInfo on terms, as this will be super confusing when merging ontologies:
<http://w3id.org/obook/A> rdf:type owl:Class ;
                          owl:versionInfo <http://purl.obolibrary.org/obo/cl/releases/2021-09-09/cl.owl> .

👍 : You agree with this 👎 : You disagree with this (add comment) 👀 : Sounds interesting, but why should I care

matentzn commented 2 years ago

cc @dosumis @hkir-dev @cmungall

hlapp commented 2 years ago

The definition of owl:versionInfo is the following: An owl:versionInfo statement generally has as its object a string giving information about this version, for example RCS/CVS keywords. It sounds like what you propose to use it for is two things conflated into one, namely in which ontology was this defined, and at which version. It's not obvious to me why rdfs:isDefinedBy is not suitable for this, nor why owl:versionInfo is more suitable. (It seems if any thing it's the opposite.)

~Also, your logic for finding this appropriate for axioms but not for classes ("terms") (meaning it could be appropriate for the axiom(s) defining a class but not for the class definition) to me makes its rationale internally contradicting, i.e. inconsistent.~

matentzn commented 2 years ago

Just to be clear, the proposal on rdfs:isDefinedBy stands as you suggest, this has nothing to do with it. The one is concerned with what is the terms' conceptual home (rdfs:definedBy http://purl.obolibrary.org/obo/mondo.owl), the other, this proposal here, is solely concerned with versioning. I don't really care about the exact generally has as its object a string phrasing, but if you insist, we could use the string representation of the version (2020-02-01) instead of the full IRI. This means though that it always needs to go alongside the rdfs:definedBy pattern, otherwise it loses its meaning. Perhaps that is ok, but I don't really see the advantage here..

matentzn commented 2 years ago

Also, your logic for finding this appropriate for axioms but not for classes ("terms") (meaning it could be appropriate for the axiom(s) defining a class but not for the class definition) to me makes its rationale internally contradicting, i.e. inconsistent.

I don't understand this sentence I am afraid.. I am just saying that the Term IRI itself should not be versioned, it should be eternal. Can you explain what the problem is with that?

hlapp commented 2 years ago

The advantage is to stay with published definitions of reused terms and properties as closely as possible when using shared ontologies, rather than overlaying your own definition. After all, isn't that the point of using shared ontologies?

matentzn commented 2 years ago

It is, but one ontology O1 may import an old definition, one O2 a newer one. And you may import both of these (O1 and O2) into an ontology O3, so you want to be able to see where these are from. Same for conflicting axiomatisation. It would be super useful if we can pinpoint a given axiom to which version of an ontology it came from.

Lets not make this issue about the pros and cons of reusing terms or not redefining stuff in your own ontologies. Its happening whether we want it or not.. This issue is just about 1 thing: How should we reflect, if we so want to, which version of an ontology a statement (annotation assertion or axioms) comes from... :) Hope that makes sense.

hlapp commented 2 years ago

Also, your logic for finding this appropriate for axioms but not for classes ("terms") (meaning it could be appropriate for the axiom(s) defining a class but not for the class definition) to me makes its rationale internally contradicting, i.e. inconsistent.

I don't understand this sentence I am afraid.. I am just saying that the Term IRI itself should not be versioned, it should be eternal. Can you explain what the problem is with that?

I don't think there'a a problem with that, but if we agree on that, I don't see why it nonetheless is a problem with axioms. I.e., I don't really understand what the problem is for axioms that needs your proposed solution.

Having said that, my concern here is not at all whether axioms can be linked to some version of a vocabulary. In fact, I think if someone wants to state that link they should be able to, and for community ontologies there should be guidance as to how to do this so it's done consistently. (This is probably part of one of your goals here.) So let me strike that second part of my earlier comment. What is my main concern here is to recommend using a property of a shared ontology (OWL) in a way that seems (to me) inconsistent with its published definition, especially when there seems to be a way to achieve the desired annotation in keeping with published definitions.

matentzn commented 2 years ago

I see where you are coming form, ok. Axioms in our world are not eternal, they are constantly being revised, corrected constrained further, relaxed etc.. Same as textual definitions.

I see your point on misusing owl:versionInfo. I kinda prefer misusing it over minting new properties, but I am happy to be overruled if there are many against this slight misuse. The phrasing in the spec is somewhat ambiguous (generally has as its object a string) - it could mean that "in general it is a string, but there are cases...". No worried.

@jonquet may have an opinion about that as well?

jonquet commented 2 years ago

Hi.

To some extend, the rdfs:isDefinedBy property should be able to say what you like to say @matentzn An axiom (or any other object in an ontology) do not really have a version. It has the version of the ontology it is in. However, it may have been declared/defined in a specific version of the ontology which is why the rdfs:isDefinedBy must always use a version specific URI.

Therefore, I don't think we really need a version system for axioms (or any other object in an ontology).

I would suggest to :

jonquet commented 2 years ago

I am adding a 2nd comment with an explanation that could be possibly ignored if one think is out of the topic:

I believe, there is maybe a confusion which comes from the OBO community practice to import term by copy/pasting them into other ontologies. Except in the OBO community (where things like ROBOT facilitate the process), RDF statement are not "repeated" in the ontology which reuses a term (or something else). Either (A) simply the external URI is used and its the system that should resolve it and find the related RDF statements or (B) the whole ontology is imported (all statements) with the owl:imports mechanism. Because the OBO community practice encourage (to facilitate reuse) the copy of the RDF statements concerning an object in the ontology reusing (and accept the burden of maintaining the dependences updated) then you are interested in keeping the version for that reused object. But in theory the whole ontology should have been imported (very annoying yes and that's why I realistically understand the OBO practice) including the statement defining the version of the ontology imported.

matentzn commented 2 years ago

Thank you @jonquet

Hard are the standardisation days. I have already tried to suggest your proposal and got strong resistance against it. I will try it again.

matentzn commented 2 years ago

I only saw your second comment later after I sent my response. We need to distinguish between the copy paste practice which I live to ban from OBO, and the concept of dynamically import portions of (potentially huge) external ontologies into ones own ontology (module extraction). In our experience, users of ontologies do not know how to handle owl:imports, and for many purposes they create huge problems. No-network environments make it impossible to resolve them. It's a pain to manage their versioning (maybe it's not even possible). It makes the ontology vulnerable to network outages. and and.. isn't it perhaps true that outside the OBO world, ontologies that are imported are either small or very stable (bfo, foaf, void etc) and that many ontologies outside the obo sphere simply don't have that degree of inter-connectedness?

jonquet commented 2 years ago

I share your thoughts in the last comment.

jamesaoverton commented 2 years ago

@jonquet Your perspective is very welcome and appreciated. I think that characterizing current OBO practises as "copy/pasting" is uncharitable, so I'd like to expand on @matentzn's response.

In OBO we are building a variety of OWL artifacts that include axioms from multiple ontologies, each of which changes continually with the state of its scientific domain. If this does not fit the goals and promise of the Semantic Web, then I've made a terrible mistake somewhere along the line.

The old joke says that there are only two hard things in computer science: cache invalidation and naming things. I would rephrase those as "change" and "identity". In OBO we have at least these kinds of things that we need to identify and track:

There are analogies to versioning in software, but I think they're not a good match for OBO. The unit of reuse for software is usually the "library", and below that level people "copy and paste" from one file to another. The unit of reuse for ontologies in general is not as clear to me, but in many cases it's a single stable OWL file, and the analogy to software is close enough. The unit of reuse in OBO is much less clear: sometime the term, sometimes a primary OWL artifact, sometimes a versioned OWL artifact, and increasingly an axiom set. I've seen proposals for software versioning down to the level of functions (Unison is my favourite), and they are much more difficult to get right than versioning libraries.

We haven't solved these problems, and maybe we've made things harder for ourselves than they have to be, but they are not trivial problems.

jonquet commented 2 years ago

@jamesaoverton thanks for reply. I totally agree with your comments, those issues ARE hard. And there is a big distance btw theory and practice. My remark was not to comment/evaluate/discuss the OBO practice and the "copy/pasting" pasting expression was a shortcut ;) My intention was just to tentatively explain the elements discussed in the thread above not to start a polemic on "reuse".