Re: oa:modelVersion

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 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". 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 and, say http://www.openannotation.org/spec/core/20120509.rdf

- 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 ;-) )

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>
>     [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> <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>
>         (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://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 <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:08:36 UTC