- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Fri, 2 Nov 2012 14:09:47 -0600
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: Antoine Isaac <aisaac@few.vu.nl>, public-openannotation <public-openannotation@w3.org>
- Message-ID: <CABevsUEKPrjGesBg2FFXskY_SGC_ov0ot-mAzoaTHKo2b6ScNw@mail.gmail.com>
To try and express a concrete example of Antoine's concern, if I understand correctly... A client is trying to render an annotation that uses OA and OAX. With just the link to OA Core, you can't determine which version of OAX is being used, as it is likely not in step with OA. Now add in DC, Prov and two community specific extensions and that little modelVersion really doesn't do us any good at all. Maybe we do drop it under the not-really-useful-to-anyone test? Or include a timestamp and leave it up to other systems to determine the version of all of the namespaces that was in use at that time? Rob On Fri, Nov 2, 2012 at 12:23 PM, Paolo Ciccarese <paolo.ciccarese@gmail.com>wrote: > > > 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 20:10:18 UTC