Re: oa:modelVersion

Hi,

Sorry in advance for yet another long trolling, but I wanted to discuss for a while.

Is there somewhere a documentation on how this versioning info ended up modelled this way?
I understand the requirement, but I have doubts whether it should be handled like this in the core of the OA model.


(1) It should be quite a minor requirement.

The requirement is crucial in theory, but it's best tackled by not raising the issue that motivate it in the first place. The best practice is really to keep a vocabulary as stable and backwards-compatible as possible!

Of course it's difficult when the model is still being worked on. But once an "official"/"stable" version is released, any change that is not backwards-compatible should be strongly discouraged--at least when it would impact a lot of existing data.


(2) It's questionable whether a domain model like OA should support vocabulary-level versioning.

The problem of data and model versioning applies across the board, for every data that is created. If you want to apply it to OA, you may want to have it for the other vocabularies used with it: DC, etc.... If all of them included a specific versioning mechanism, interoperability would just vanish.
In general one would count on specific representation feature in the data model (like named graphs in RDF) or a very specific "meta-domain" vocabulary like PROV or the Resource Map part of OAI-ORE [1]. Possibly in combination...

The awkwardness of trying to address at the OA level shows in the issues raised by attaching the version data to the Annotation resource. Why should it be considered a property of the Annotation? And how to interpret it when consuming data from different contexts? (E.g., if two annotations "with different models" share a same target with its Selector.)

On a different level, the current solution may fall short when elements remain stable across versions. How should one decide if two statements with a "same" property are directly interoperable or if they shouldn't be mixed? Will the vocabulary include some time-stamped resources for each element, as in DC [2]?


I'm ready to accept that there are alternative views, or even scenarios I would have overlooked. But meanwhile I am truly convinced that the current situation is sending quite bad signals...


If we really want to say something about versioning data then I'd rather:

- keep track of the version information at the general vocabulary level (OWL ontology files published at different URIs with version info in it like owl:versionIRI [3])

- recommend the use a meta-level scheme (PROV, OAI-ORE, Named Graphs, whatever) for linking data graphs or "records" to these versioned ontologies

And then leave to the people who don't trust OA to be stable the burden of exploiting that in the way they see fit.
All others will be alright never have been presented this data (especially if is represented in a inappropriate way).

Antoine

[1] http://www.openarchives.org/ore/1.0/primer
[2] Cf. http://dublincore.org/usage/terms/history/#tableOfContents-003 . Of course not many really use it outside of the DC documentation...
[3] http://www.w3.org/TR/owl2-syntax/#Versioning_of_OWL_2_Ontologies . This could be also handled with http://www.w3.org/TR/swbp-vocab-pub/, possibly with Memento-like http redirections.



> +1
>
> I am currently using that URL as the model version.
>
> Paolo
>
>
> On Thu, Nov 1, 2012 at 4:31 PM, Bob Morris <morris.bob@gmail.com <mailto:morris.bob@gmail.com>> wrote:
>
>     Is there, or could there be declared, a suitable value of
>     oa:modelVersion corresponding to
>     http://www.openannotation.org/spec/core/20120509.html
>     (how about, dare I say it, use that as the value)?
>
>     In our annotation generation and consumption components, RuleML
>     rules, SPARQL queries from forms, ...., we are starting to move from
>     AO to OA. Embedding an oa:modelVersion in our annotations would help
>     us keep track of exactly where we stand, especially as OA evolves and
>     we find we need to make changes. We have several parts of our system
>     that all need to be using the same annotation vocabulary. I guess we
>     don't need a standardized oa:modelVersion, but we are also beginning
>     to think about the scope of our collaboration with others working on
>     the same kinds of biodiversity data annotation using OA. The more
>     agreement on modelVersion the less confusion...
>
>     Bob
>
>
>     --
>     Robert A. Morris
>
>     Emeritus Professor of Computer Science
>     UMASS-Boston
>     100 Morrissey Blvd
>     Boston, MA 02125-3390
>
>     IT Staff
>     Filtered Push Project
>     Harvard University Herbaria
>     Harvard University
>
>     email: morris.bob@gmail.com <mailto:morris.bob@gmail.com>
>     web: http://efg.cs.umb.edu/
>     web: http://etaxonomy.org/mw/FilteredPush
>     http://www.cs.umb.edu/~ram <http://www.cs.umb.edu/%7Eram>
>     ===
>     The content of this communication is made entirely on my
>     own behalf and in no way should be deemed to express
>     official positions of The University of Massachusetts at Boston or
>     Harvard University.
>
>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender.
> If you have received this message in error, please notify the sender immediately.
>

Received on Friday, 2 November 2012 13:45:56 UTC