7
3

With the property owl:versionInfo and other related ones, I can define version information of an ontology. However, how can I relate a used ontology specification version in a description?
For namespace definitions (as far as I know) it is a good practice to use a/the (version unspecific) PURL of a ontology specification, because "cool URIs don't change". This PURL should usually resolve to the latest version of the ontology specification.
So imagine now the following scenario:

  1. I decribed my instances by utilizing version 0.1 of an ontology specification
  2. The author of this ontology specification change now some parts of this ontology significantly (weel it's just version 0.1 ;) ) and version 0.2 is somehow incompatible to version 0.1
  3. The author included, of course, descriptions in both versions of the ontology specification that relate them somehow (e.g. owl:priorVersion etc.)
  4. An information consumer requests my instance descriptions and thereby resolves the namespace of the ontology specification, which directs now to version 0.2
  5. The information consumer cannot fully interpret the instance data, because he/she/it doesn't know which version I used for describing the instance data.

This leads to the conclusion, that one has explicitly define somehow the used version of an ontology specification.

A proposal of a solution is:

  1. Introduce a new property that explicitly relates the version specific PURL of the ontology specification e.g., ex:thisVersion (dc:hasVersion, dc:isVersionOf are to broad here).
  2. Use the version specific PURLs for prefix definitions
    or
  3. Use dcterms:conformsTo to related the version PURLs of the applied ontology specification versions. This would double the description amount (prefix and conformatsTo definitions).

What do you think about this proposal? Did I oversee an existing property for ex:thisVersion (I looked at several ontology specification and found not really one, which at least provide also minimal version information for version tracing e.g., owl:priorVersion)?

[edit]Here is an example with two version specific IRIs of an ontology specification that uses owl:versionIRI as proposed by Michael Schneider:

the description of the owl:Ontology particular as it is part of the description that could be delivered, when resolving the canonical ontology IRI http://purl.org/ontology/co/core#:

@prefix co: <http://purl.org/ontology/co/core#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

co: a    owl:Ontology ;
    dc:title "The Counter Ontology"@en ;
    owl:versionIRI <http://purl.org/ontology/co/20100913/core#> ;
    owl:priorVersion <http://purl.org/ontology/co/20100804/core#> ; 
    ... .

the description of the owl:Ontology particular as it is part of the description that could be delivered, when resolving the version IRI http://purl.org/ontology/co/20100913/core#:

@prefix co: <http://purl.org/ontology/co/20100913/core#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

co: a    owl:Ontology ;
    dc:title "The Counter Ontology"@en ;
    owl:versionIRI <http://purl.org/ontology/co/20100913/core#> ;
    owl:priorVersion <http://purl.org/ontology/co/20100804/core#> ;
    dc:isVersionOf <http://purl.org/ontology/co/core#> ; 
    ... .

instance description that references the applied version of an ontology directly via its prefix definition (which can automatically be inferred by applying a rule that uses the object of the owl:versionIRI for the prefix definition, instead of the ontology IRI):

@prefix co: <http://purl.org/ontology/co/20100913/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix ex: <http://example.org/> .

ex:WebpageCounter a co:Counter ;
   dc:title "Webpage Counter"^^xsd:string ;
   ... .

instance description that references the applied version of an ontology via a dcterms:conformsTo relation:

@prefix co: <http://purl.org/ontology/co/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix ex: <http://example.org/> .

<> dcterms:conformsTo <http://purl.org/ontology/co/20100913/core#> .

ex:WebpageCounter a co:Counter ;
   dc:title "Webpage Counter"^^xsd:string ;
   ... .

Which version of the association of the applied ontology in instance description would you prefer? [/edit]

PS: we may need also a further property to explicitly address the latest version of an ontology specification, which should usually also be served by resolving the (version independent) PURL of the ontology specification

PPS: explicitly define the used ontology specification version by using an owl:versionInfo relation with the ontology specification PURL as subject and the used version as object wouldn't work, because then I would normally have two owl:versionInfo triples of this ontology specification in my knowledge base (on of the ontology specification itself and one of the instance description)

Edit2:

related sources:

asked 27 Jan '11, 12:03

zazi's gravatar image

zazi
3.4k1213
accept rate: 13%

edited 02 Apr '11, 11:14

BTW, I found this RFC (http://tools.ietf.org/html/rfc5829) which address link types for versioning relations.

(29 Jan '11, 15:09) zazi zazi's gravatar image
1

I have fully revised my original answer, after I have found that my answer did not really meet your question.

(05 Mar '11, 23:05) Michael Schn... ♦ Michael%20Schneider's gravatar image

Edit Comment: I now see that I did not understand you correctly when I gave my original answer. Your question is indeed a very important one. It is relevant for virtually any Linked Open Data data node. But I wonder whether it has ever been discussed before. I have now edited my answer. What was my original answer (the core of it, at least) is still relevant, but more as technical preliminaries.

Preliminaries:

OWL 2 introduces the new property owl:versionIRI, which can be made a part of the ontology header. The idea is that you can have different versions of an ontology by combining always the same ("cool" :)) ontology URI with a version-specific version URI.

See http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_IRI_and_Version_IRI for details.

Actual Answer:

In an ideal world (that is, in an OWL 2 compliant world ;-)), all ontologies being referred to from the instance data have both an ontology URI and a version URI. At the location denoted by the version URI is the physical ontology versions. The latest ontology version is additionally available from resolving the purl'y ontology URI.

Provided this scenario holds (which will, of course, almost never be the case today), then the minimal-correct solution is in my humble opinion:

refer to the ontology by an `owl:imports` directive 
that points to the /version/ URI of the ontology.

This approach is necessary: If you instead use an import directive on the "generic" ontology URI, then the semantic meaning of your data is likely to change with every update of the referenced ontology. It's like for citing Wikipedia articles: if you really want to do this, then cite a specific revision, otherwise you'll cite something different all ten minutes or so.

This approach is sufficient: Technically, you now obviously get the intended semantics for your data in a stable way. In addition, the imports directive acts as a declaration for anyone to see what vocabulary you are referring to /precisely/.

Additional notes:

  • What is a bit sub-optimal is that within the instance data the generic ontology URI and by this the "abstract" ontology isn't mentioned anymore, but only a version instead. Two things come to mind. Firstly, in our ideal world it is still possible to find out about all the abstract ontologies by retrieving all imported ontologies (from their version URIs) and look up their ontology URIs. Secondly (and this even works in the real world :-)), you can add some additional annotations to the ontology header of the instance data, which inform about the abstract ontologies being used. I don't have a clear opinion on what annotation property is best suited for this and how to do the referencing. Maybe just adding a collection of rdfs:isDefinedBy annotations that point to all the "abstract" ontology URIs? What gets lost in this way are the associations between ontology URIs and version URIs. One could, of course, also add a couple of rdfs:comment annotations telling the associations in natural language. There could also be some central service that allows to make lookups from ontology versions to respective generic ontology URIs. After all, there is no technical requirement for having the association within the instance data, it would just be nice for a human to have the information being presented to him by his ontology editor - and for this, comments or ontology look ups performed by the ontology editor should be sufficient.

  • If the referred ontologies include owl:backwardCompatibleWith and owl:incompatibleWith notes, then it is even possible for someone to find out that perhaps the data still complies with a newer version of the referenced ontology, or not. Again something, that ontology engineering tools may easily support.

  • If the world isn't perfect, i.e. no ontology URI / version URI pairs, and if there are not even physical versions on the SemWeb, but the old ontology version is simply overwritten by the new version, reusing the same "abstract" ontology URI, then we have a problem - and, actually, we probably had this problem for a long time (watch out for the original OWL 1 version of owl.owl, for example!). In this case, all the instance data publisher can do is to check whether something critical has changed and, if necessary, make updates to his data. But then, the consumer of the instance data will be the next one who has effectively the same problem...

  • You can still use the ontology URI / version URI schema for your instance data as well. So you have then concrete versions of instance data referring (via owl:imports) to concrete versions of ontologies.

  • I think that a "lastest-version" marker should really be somewhere outside the actual ontology, because if you have it within an ontology, you have to change the ontology, when there is a new version available.

permanent link

answered 28 Jan '11, 15:13

Michael%20Schneider's gravatar image

Michael Schn... ♦
6.2k1712
accept rate: 34%

edited 05 Mar '11, 23:04

Ah, thanks for the hint Michael. I looked yesterday also in the OWL 2 documentation, however, I didn't find owl:versionIRI (I also looked especially at the changes-between-OWL1-and-OWL2-document). Anyway! Re. the "latest version" marker. Normally, one assumes that one will retrieved the latest version by resolviing the canonical (version indepent) ontology URI. If this would be somehow formally manifestation, then one wouldn't need a separate "latest version" marker that has to change on every update.

(28 Jan '11, 16:39) zazi zazi's gravatar image

A version specific description is then "about" the version IRI, not the ontology IRI, or? - example for http://purl.org/ontology/co/20100804/counterontology.owl I should use http://purl.org/ontology/co/20100804/core# rather than http://purl.org/ontology/co/core# (the latter is currently the case, which I guess is wrong). The ontology IRI can then be related by e.g., dcterms:isVersionOf. Does this makes sense? PS: any suggestions to the application of the version linking in instance data?

(28 Jan '11, 16:45) zazi zazi's gravatar image
1

@zazi: For your first comment: I guess that, even without an "official" policy, it will/should become common practice that the latest version of an ontology document is available at the ontology's generic ontology (HTTP-)URI, while the different versions are available at their specific version URI. Similar as for W3C standards: There is the latest version of the OWL 2 Overview at http://www.w3.org/TR/owl2-overview/, while the different working drafts have a specific version URL, e.g. http://www.w3.org/TR/2009/REC-owl2-overview-20091027/ for the same document.

(28 Jan '11, 16:58) Michael Schn... ♦ Michael%20Schneider's gravatar image

@zaki: Can you please explain what you mean by "version linking in instance data"? If you mean the whole data knowledge base, then I see no reason not to use the same approach as for "ontologies", i.e. add an ontology header with ontology IRI and version IRI. If you mean the terms within a knowledge base, this would then probably rather be something like "defined as of version N.M". Why not adding /two/ rdfs:isDefinedBy annotations to the term: one pointing to the generic ontology URI, and one to the version URI, where the term has been defined originally?

(28 Jan '11, 17:06) Michael Schn... ♦ Michael%20Schneider's gravatar image

Adding to my last comment: You can even use rdfs:isDefinedBy for single statements in your data, as this property is an annotation property and OWL 2 has introduced "axiom annotations", see http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Annotations. In RDF, it's pretty ugly, since it is a kind of reification, but with the special purpose of annotating axioms. See http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Translation_of_Axioms_with_Annotations.

(28 Jan '11, 17:22) Michael Schn... ♦ Michael%20Schneider's gravatar image

I added an example. I hope that clarifies what I mean by "version linking in instance data".

(28 Jan '11, 18:08) zazi zazi's gravatar image

PS: please note also the different IRIs of the co: prefix of the ontology descriptions (from the canonical ontology IRI and version IRI).

(28 Jan '11, 18:10) zazi zazi's gravatar image

Michael, thanks a lot for revising your answer. I think the associations between ontology URIs and version URIs are already made in the ontology specifications themselves, or? Regarding the "lastest version" marker issue, I guess, that one might treat the ontology URI as a kind of defacto standard for it. To conclude, you are suggesting to use owl:imports for relating the utilized version of an ontology. However, which URI would you use for the prefix definitions in the instance data? - The ontology URI or the version URI? Btw, any reasons against utilizing dcterms:conformsTo?

(06 Mar '11, 11:10) zazi zazi's gravatar image
1

/Prefix definitions:/ Obviously, for the vocabulary terms you are applying in your instance data, you have to use the same URIs as used in the ontology where they are defined. Otherwise, you are talking about entirely different things technically. Now, for the ontology provider, it is highly advisory to use the generic ontology URI instead of the version URI, otherwise his ontology will change fundamentally with each revision (the prefix URI would change every time). So, in all realistic cases, the answer will be: the prefix should resolve to the /ontology URI/.

(06 Mar '11, 12:19) Michael Schn... ♦ Michael%20Schneider's gravatar image
1

/Association between ontology URI and version URI:/ Yes, this is (provided our ideal world, where there are always an ontology URI and a version URI) made in the ontology itself. An ontology engineering tool will have to retrieve the referenced (by owl:imports) ontology versions anyway and can then make an additional lookup what the generic ontology URI is. It's a simple thing, if the convention of having an ontology URI and a version URI is followed by the ontology providers. I hope, that this will be the case in the future.

(06 Mar '11, 12:26) Michael Schn... ♦ Michael%20Schneider's gravatar image
1

/Latest version marker:/ Yes, I agree that one should always get the latest version by resolving the generic ontology URI. That was one of my earlier comments above.

(06 Mar '11, 12:30) Michael Schn... ♦ Michael%20Schneider's gravatar image

/dc:conformsTo :/ Here, I cannot say whether using this property to indicate the used ontology is ok from its intended use. Other people have to check. But I can at least say one thing: using dc:conformsTo would, in comparison to owl:imports, be purely informal and informational, so it cannot technically hurt to use it, at least. Having already owl:imports to point to the ontology version would, of course, make the additional use of dc:conformsTo a bit redundant IMO. Such redundancy should somehow pay off (e.g, if certain tools make use of it), but I don't know enough about this.

(06 Mar '11, 12:42) Michael Schn... ♦ Michael%20Schneider's gravatar image

Thanks a lot again for your answers, Michael. Regarding the usage of dcterms:conformsTo. I viewed it as a substitution for owl:imports in that context. So, no redundancy at all. Simply, due the case that the usage owl:imports implies the import of the references ontologies. Some people may do not want this. Albeit, it currently seems, at least for me, that this is the safest way to related the utilized version of an ontology. Finally, I'm unsure, whether it is good to type every description as owl:Ontology. However, it aligns more to the definition of ontology from metaphysics in that context.

(06 Mar '11, 14:53) zazi zazi's gravatar image
2

Ah, I did not understand that you consider not using owl:imports at all. I generally recommend to add an OWL ontology header not only to vocabulary definitions but also to datasets, and to use owl:imports statements whenever terms from an OWL vocabulary are applied. Only this ensures that the terms are used with their defined meaning. I see no problem with using owl:imports: in the worst case, tools such as RDFS tools, will silently ignore the statement. But OWL tools will be able to make good use of the directive. Btw: an ontology header is, in its simplest form, just one more triple. :-)

(06 Mar '11, 21:48) Michael Schn... ♦ Michael%20Schneider's gravatar image

Hm, maybe we should go that way in Linked Data environments. Currently, I avoided to utilize owl:imports in instance data.

(07 Mar '11, 00:00) zazi zazi's gravatar image

I thought this this question should be automatically marked as "answer", or? (since the time of the bounty expired)

(11 Mar '11, 17:57) zazi zazi's gravatar image

No idea how this works. You may retry, with another interesting question. :)

(16 Mar '11, 20:53) Michael Schn... ♦ Michael%20Schneider's gravatar image

Okay, it seems that bounties are not available in the new Q&A board software. Anyway, I can mark this answer at least as accepted now ;)

(07 Apr '11, 18:14) zazi zazi's gravatar image

Is this proposal still valid as of December 2013 ? For the dataset, do you propose to add an owl:import on the ontology version URI, and use that (cool) ontology URI for the @prefix ? Thanks for the information. Fabian

(04 Dec '13, 08:14) Fabian Cretton Fabian%20Cretton's gravatar image
showing 5 of 19 show 14 more comments

Might be useful to read first. It makes pretty good sense:

http://semver.org/

permanent link

answered 31 Oct '12, 08:55

William%20Greenly's gravatar image

William Greenly
5.1k412
accept rate: 13%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×667
×10
×4

question asked: 27 Jan '11, 12:03

question was seen: 2,908 times

last updated: 04 Dec '13, 08:14