W3C home > Mailing lists > Public > public-openannotation@w3.org > November 2012

Re: oa:modelVersion

From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
Date: Fri, 2 Nov 2012 14:23:53 -0400
Message-ID: <CAFPX2kDneGWSXYVPrJqMv-be+t5xY2wUuH_j5oNMGfg2QCXydw@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
On Fri, Nov 2, 2012 at 2:08 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Rob,
> Thanks for the explanation. Indeed it's a tricky issue, and it's maybe
> good to work on it after the dust has settled a bit on the others. In fact
> the fact that we're discussing a lot does not create a mindset that helps
> conceiving that OA will be much more stable than now, one day ;-)
> And of course we'll need some time to look at available receipes around us.
> Trying to react at some points:
> - namespace: indeed it's imperative to use only one namespace for each
> vocabulary. The DC solution I've mentioned is no exception. As I
> understood, it, the time-stamped URI are in fact rather version "numbers",
> not property URIs that would replace the canonical one in RDF graphs.
> - "using the URI of the core spec". Are you meaning the option that Bob
> and Paolo mentioned, i.e. have http://www.openannotation.org/**
> spec/core/20120509.html<http://www.openannotation.org/spec/core/20120509.html>as the value for oa:modelVersion ? Indeed even if I fully accepted using
> oa:modelVersion, I'd still have doubts about that one. ".html" indicates a
> document, not a version of an ontology, which in my mind is a bit more
> abstract. I'd rather use "http://www.openannotation.**
> org/spec/core/20120509 <http://www.openannotation.org/spec/core/20120509>".
> It looks like splitting hair, but already avoids a lot of ambiguity. Of
> coruse then best practice would recommend that if looks up the URI you can
> serve the corresponding version of the spec, i.e.,
> http://www.openannotation.org/**spec/core/20120509.html<http://www.openannotation.org/spec/core/20120509.html>and, say
> http://www.openannotation.org/**spec/core/20120509.rdf<http://www.openannotation.org/spec/core/20120509.rdf>

I could work with "http://www.openannotation.org/spec/core/20120509" . I
was using the .html as, right now, it resolves... for human consumption at

> - the point on serializedAt, serializedBy is very interesting. Indeed if
> the property had been "oa:serializationModel" then I might have been less
> anxious about it. When properties look like humble "short-cuts" of some
> more complex paths. I'm less enclined to think that you wanted to solve the
> vocabulary versioning problem within the entire graph... And it seems like
> it would be less vulnerable to corner-case but real situations, e.g. if a
> same annotation happens to be serialized using different models at
> different times.
> (but that being said, I still don't think it's optimal ;-) )

I could go wither way.  I would not mind to change "modelVersion' to
"oa:serializationModel" or similar as it is specifying better that is a
serialization thing and not a property of the Annotation itself.


> Antoine
>> 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 <mailto:
>> 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><
>> 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><
>> 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><
>> 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/> <
>> 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> <mailto: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><
>> 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>
>> <mailto: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://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/ <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 <tel:%2B1-857-366-1524> (mobile) +1-617-768-8744<tel:%2B1-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 18:24:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:02 UTC