- From: Lutz Suhrbier <l.suhrbier@bgbm.org>
- Date: Mon, 05 Nov 2012 13:24:35 +0100
- To: public-openannotation@w3.org
- Message-ID: <5097B003.4020009@bgbm.org>
Just an idea ... What if the OA generating agent provides a mapping list of prefixes, versions and namespaces he has used to create the OA annotation ? Something that corresponds to Jena's PrefixMapping factory classes. Ultimately, only the generator knows what standards and version he was using when creating the annotation, so let's provide him means to simply document that ? best regards Lutz > > > On Fri, Nov 2, 2012 at 4:09 PM, Robert Sanderson <azaroth42@gmail.com > <mailto:azaroth42@gmail.com>> wrote: > > > 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. > > > That is a problem indeed. > > > 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? > > > I am not sure that would work. Applications come and go. I would > prefer having a serialization that is more explicit - includes the > version of the model - and survives the application. > Plus who knows, maybe some applications will be able to > consume/produce multiple versions at one point so the timestamp would > not help. > > Paolo > > > On Fri, Nov 2, 2012 at 12:23 PM, Paolo Ciccarese > <paolo.ciccarese@gmail.com <mailto:paolo.ciccarese@gmail.com>> wrote: > > > > On Fri, Nov 2, 2012 at 2:08 PM, Antoine Isaac <aisaac@few.vu.nl > <mailto: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 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 > > > 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> > <mailto: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>> > <mailto: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>> > <mailto: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> > <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> > <tel:%2B1-857-366-1524> (mobile) +1-617-768-8744 > <tel:%2B1-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. > > > > > > > > > > > -- > Dr. Paolo Ciccarese > 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 Monday, 5 November 2012 12:25:03 UTC