We have started an effort within the W3C, in the form of a Community
Group, to reconcile the Annotation Ontology and OAC vocabularies.
Anyone is welcome to join the group who is interested in this process,
however please be aware that initially the editors of the
specifications will work offline to come to a baseline set of
agreements. We expect this to be completely before Summer 2012.
The blurb for the group:
The purpose of the Open Annotation Community Group  is to work towards
a common, RDF-based, specification for annotating digital resources.
The effort will start by working towards a reconciliation of two
proposals that have emerged over the past two years: the Annotation
Ontology  and the Open Annotation Model . Initially, editors of
these proposals will closely collaborate to devise a common draft
specification that addresses requirements and use cases that were
identified in the course of their respective efforts. The goal is to
make this draft available for public feedback and experimentation in
the second quarter of 2012. The final deliverable of the Open
Annotation Community Group will be a specification, published under an
appropriate open license, that is informed by the existing proposals,
the common draft specification, and the community feedback.
What kind of community is it that starts off behind closed doors like
that? In the future I'd rather not know if there are conversations
going on behind closed doors as part of a "community" process. I'd
like to believe that open communities can exist at the w3c and
elsewhere, even if my belief in Santa Claus has recently started to
feel a bit wobbly.
PS. I will admit that perhaps this is a hot button issue for me right
now, and that I'm way of base :-)
I do think it's a reasonable question to ask: why the "work offline" thing?
I don't really want to be involved in the process, but do think it's
more legitimate, and likely to end up with a better result (including
potentially wider support), if it's done in the open.
Again, totally an outsider to the whole thing at this point.
You may be a bit off base here. :-) You can sign up for the mailing list (which I have just done).
Also, I think it makes perfect sense for the OAC and AO editors to come up with a first draft of the merged spec. It is what I would do in their place, as it is easier to deal with responses and fixes on a concrete document instead of arbitrary discussion.
Having said that, I would think that something could be prepared much earlier than 6 months from now. I would like to see a first draft (not a first complete visible version), and would like to see it around Jan 31. I just want to know broadly what they are thinking of for the alignment. But if it really bothered me, I could draft up my own merger of the two specs and send it to them to consider - and then to this list if I didn't think they were considering it. Frankly, it doesn't bother me that much. I have other plans for things to work on over the holidays. :-)
What I am more concerned about is what set of requirements they will be trying to satisfy. Annotations are one way of designing some stuff I need to do, but we also have a set of requirements that I don't think AO and OAC plan to deal with. That's fine, my requirements are not everyone else's, but it would be nice to have a list of the ones they think are in and out of scope for their work.
Why offline? Because we want to get something done quickly. We hope,
in fact, to get a merged specification draft out *very* quickly (early
March maybe?) in order to get feedback on it, and then iterate based
on that community feedback.
What we don't want to do is rehash every single discussion that has
taken place in both communities (AO and OAC) already, over a
comparatively slow, asynchronous communication medium, when the
editors from both specs know why their community came to the decisions
that they did, and we have already discussed them in person. If there
are new issues, then we will absolutely take them into account...
There hasn't been ANY discussion of the issues that have been raised
on this list. I refer you to my posts about the discussion documents
referenced from the current OAC beta specifications. There has been,
and of course still is, opportunity for open discussion, yet no one
has taken it. If you feel strongly about engaging in open discussion,
please please respond to the open questions!
As Doug says, the point of the offline meetings is to agree on the
fundamentals such that there is a framework for discussion, based on
both groups' experiences and communities. Agreeing on some basic,
shared terminology. Comparing existing use cases and trying to model
each community's use case, in the other's data model.
If anyone has the time to devote to actually *working* on these sorts
of tasks, over the next three months, we would be *very* happy to
include you in the discussions. What we do not want to do is delay the
reconcilliation efforts and the joining of the two communities by
waiting while people kibbitz unproductively in the background.
On Tue, Dec 13, 2011 at 12:36 PM, Daniel, Ronald (ELS-SDG)
> Having said that, I would think that something could be prepared much earlier than 6 months from now. I would like to see a first draft (not a first complete visible version), and would like to see it around Jan 31. I just want to know broadly what they are thinking of for the alignment. But if it really bothered me, I could draft up my own merger of the two specs and send it to them to consider - and then to this list if I didn't think they were considering it. Frankly, it doesn't bother me that much. I have other plans for things to work on over the holidays. :-)
The holidays are why we set the time frame as we did, plus that we're
all working on other projects and deadlines at the same time (of
The two specs are definitely already closely aligned, with the
differences coming primarily from OAC's top down approach (research,
model from use cases, implement, iterate) and AO's bottom up approach
(implement use case, add to model, iterate), so we are confident that
we'll quickly be able to end up a the best-of-both-worlds solution :)
As we progress, we'll be sure to post updates and/or documents as they
become ready for public consumption. The first such document planned
is a revised Guidelines and Principles document to update the now
> What I am more concerned about is what set of requirements they will be trying to satisfy. Annotations are one way of designing some stuff I need to do, but we also have a set of requirements that I don't think AO and OAC plan to deal with. That's fine, my requirements are not everyone else's, but it would be nice to have a list of the ones they think are in and out of scope for their work.
We will satisfy all of the requirements that we know about, that can
be described using a web-centric architecture. If you would like to
describe the use cases either on-list, or by private email if that
would be preferable, we'd be happy to go through them :) This would
be particularly helpful at the moment, as we work on the revised
I completely understand. Honestly, this seems like valuable work to do
on a community discussion list so there is at least a record of the
conversations that isn't strewn across a bunch of personal inboxes.
You might even get more people participating if the discussion seemed
more legitimate, and less of a fait-accompli.
> If anyone has the time to devote to actually *working* on these sorts
> of tasks, over the next three months, we would be *very* happy to
> include you in the discussions. What we do not want to do is delay the
> reconcilliation efforts and the joining of the two communities by
> waiting while people kibbitz unproductively in the background.
Makes perfect sense to me.
Disruptive Technology Director
Re. requirements - the things I am talking about are the same ones presented in the Chicago workshop (http://www.openannotation.org/documents/ProductionPublishing.pdf) where we are looking at adding standoff markup to XML (or other) files to represent subject tagging, named entity recognition, and other kinds of markup.
· Staff and Infrastructure that are XML-capable but not RDF-capable.
· Making provision for debugging.
· Representing info beyond linguistic and ontological markup, particularly representing info on the QA of tags (aka Provenance)
· Communicating with contractors who send markup, and also suggest new ‘topics’ for the taxonomy.
· Different workflows for different publications.
· Simple handling of fragments.
· The need to deal with unusual and evolving RDF infrastructure.
Something else that has become more of a problem rather than less is the number of triples being generated. We have some book chapters, such as glossaries, where one chapter is given more than 100k tags! This leads us to looking for ways to segment the information into things that would be of use for different audiences so we can lessen the run-time burden of storing a lot of really boring triples.
I must admit I fully understand Ed's concerns here.
More precisely, I can get your willing to make progress, but I must send my two warnings (and they're *really* friendly warnings: if I did not care about the success of your work, I would just ignore that thread...):
- don't create a W3C community group before you're ready, if you don't want discussion to happen. Now, you're going to have a community group with no life? That may backfire at some point. My advice would be to send as much discussion there as soon as possible, ready.
- don't be too optimistic about avoiding to re-hash the discussions you already had hundreds of time. This is going to happen as soon as your "community" will include more people. That's just part of the game until you've carved your spec in the marble of a wide-enough consensus. And if it happens, just consider this may be a good sign that your stuff is interesting for more people ;-)
Yes, this makes a lot of sense. How do you plan on aligning the
models? Is there a face-to-face meeting planned, or is it something
that is going to be carried out over email w/ phone conversations? Who
is involved? I don't think it's fair to call it a community process if
these things aren't known.