Re: oa:modelVersion

Hi Antoine,

There's actually very little about modelVersion.  Basically, we wanted at
least an identifier to allow systems to determine whether they have
encountered a draft, stable, or subsequent version of the model.  The
easiest way to do that was to have a pointer from the annotation to some
resource that identifies the model version.

We discussed this issue at the first f2f meeting with Dan Brickley,
regarding FOAF and namespaces.  He strongly recommended to only ever have
one namespace, and hence we didn't use that as the identifier.
Another suggestion was to use a datetime for the model (which would need to
be different from the annotation's timestamp as clients may create new
annotations after a revision to the model).  This would allow the use of
Memento, for example, to retrieve the schema or documentation that was in
use for that point in time, rather than the current schema/docs.

The reasoning for putting it on the annotation is the same as the
serializedAt, serializedBy, and mimetype going on the annotation.

Overall, it's a tricky problem! We didn't want to make it very heavyweight,
but thought it should be addressed.
And of course we agree that the model should be as stable as possible, and
only the most important changes should break backwards compatibility to the
stable spec.

We do foresee the OAX schema changing more rapidly than the Core. This
issue of versions and maintenance is the main reason for the split.  Given
that, however, using the URI of the Core spec doesn't seem sufficiently
granular?

Rob


On Fri, Nov 2, 2012 at 7:45 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> 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<http://www.openarchives.org/ore/1.0/primer>
> [2] Cf. http://dublincore.org/usage/**terms/history/#**tableOfContents-003<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<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/<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<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://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/ <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.
>>
>>
>
>