How do I know/model the applied version of an ontology specification?

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:

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.

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

http://semver.org/