- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Wed, 9 Jan 2013 14:10:18 +0100
- To: public-openannotation <public-openannotation@w3.org>
Hi Paolo, > > I've started to read the new draft. For all kind of reasons I prefer it to the old one, even if I disagree with some of the choices made, especially on the namespace [1]. Congrats to the editors for carrying out a great deal of work that goes in the right direction! > > > > In Annotation Ontology v.1 (end 2009) I created several namespaces core, selectors, types, integration modules [1]... I thought that was a nice way to organize the different concerns and to have them evolving separately. Well, almost all the people who implemented AO and got back to me, strongly criticized that approach as they found multiple namespaces annoying and overly complicated. That brought me to collapse everything in a single namespace in v.2 [2] and everybody seemed happy with that choice. I still think that having more namespaces - organized by concern - was more elegant and manageable in term of evolution, but it seemed too much of a burden for many. > > Then, with the creation of Open Annotation came the approach oa/oax. The interpretation of that split has been always a bit problematic as, I think, it was reflecting several criteria at the same time: stable vs. unstable, simple vs. complex ... We had several long discussions where the problem consisted literally in deciding where to fit a term oa or oax. Some terms were of interest for many but still unstable... and so oax became a staging area. I don't believe it is that simple to determine what is used by everybody and what is used by a few either. And that can change dramatically with time. It would require again a strategy to deprecate and bring into core terms that become accepted and/or mainstream. > > If these new specs, besides naming the levels and the tuning of some definitions/charts, are proven to be accepted, I am wondering what you would classify as extensions. I think the new organization of the documents helps the learning process but I don't think it necessarily reflects what is going to be used the most. I can envision an extension for additional selectors and multiple extensions - one for each area of interest - for collecting Motivations. Maybe another extension for states?. But these will not really effect the current documentation. So, maybe the extensions will be managed separately from these specs documents? > > [1] http://code.google.com/p/annotation-ontology/wiki/Namespaces > [2] http://code.google.com/p/annotation-ontology/wiki/v2Namespaces > I understand the issue with oa/oax. oax was had little coherence, in the end, and that's not really good. In the light of the past days' discussion, I've come to realize it's better to postpone the discussion. I just wanted to say that we shouldn't consider the situation to be fixed forever. Once we reach definitive agreement on the different parts of the spec, hopefully some natural clustering will emerge. Maybe as you suggest, maybe differently. If not, then it's no use discussing the tradeoffs on maintenance/re-usability! And I think this won't necessary impact the documentation, indeed. It's possible to manage the extensions separately from the documents, as you suggest. Even though some basic level of alignment helps. Or to be more precise, if there are 'natural' clusters/extensions to be found in the end, then I trust that a good documentation will have given hints about it beforehand. Cheers, Antoine
Received on Wednesday, 9 January 2013 13:10:49 UTC