- From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Date: Fri, 2 Nov 2012 14:23:53 -0400
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: public-openannotation <public-openannotation@w3.org>
- Message-ID: <CAFPX2kDneGWSXYVPrJqMv-be+t5xY2wUuH_j5oNMGfg2QCXydw@mail.gmail.com>
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 least. > > - 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. Paolo > > 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