[annotator-dev] Open Annotation support in Annotator
azaroth42 at gmail.com
Fri Oct 10 18:17:33 UTC 2014
1. Tags are about the target(s) of the Annotation, and are thus Bodies of
2. User holds the user name of the account, and thus the appropriate
mapping is foaf:nick
3. A note towards this -- if we don't map them somehow, then any storage
backend that uses RDF (such as Stanford's) will throw them away rather than
maintain them without understanding. I'd prefer to do some mapping to
avoid this and revise later if it's not sufficient.
On Tue, Oct 7, 2014 at 4:37 PM, Robert Sanderson <azaroth42 at gmail.com>
> There was discussion towards 1 here:
> The action items from that particular discussion I believe are:
> 1. Finalize the semantics of annotator tags
> 2. Work on the semantics of user
> 3. Either model and map permissions, or include as non-round-trippable
> JSON keys
> My opinions:
> 1. Tags are multiple bodies in OA, and thus the tag is on the Target,
> not the Annotation.
> (If that isn't the semantics desired, then (anno dc:subject "tag") could
> 2. Put the current user in foaf:nick, and allow any other property needed
> desired. Mapping would be good, but see 3.
> 3. For the short term, we could just stuff the keys in and non annotator
> systems should ignore them [goes to add a ticket for this to local code].
> In the medium/longer term it would be good to do the mapping to RDF, but
> that might be a joint deliverable with other W3C working groups.
> Thanks for kicking up the thread Nick, and apologies for the delay in my
> On Wed, Oct 1, 2014 at 11:07 AM, Nick Stenning <nick at whiteink.com> wrote:
>> Dear all,
>> Earlier today a group of us had a short call to discuss the development
>> of better native support for Open Annotation in Annotator. This email
>> is an attempt to summarise that call and provide some pointers to people
>> who are going to be working on this.
>> Without further ado, here are the key requirements for better OA support
>> in Annotator:
>> 1. Devise an OA-compatible serialisation (AKA "wire format") -- most
>> work here seems to be leaning towards a JSON-LD-ification of
>> 2. Modify Annotator so that its internal model of annotations is
>> consistent with the OA data model. In particular, this means support for
>> multiple (typed) selectors and we may need to consider annotations with
>> multiple bodies and targets (as allowed by the OA spec).
>> 3. Implement (probably in annotator-store) an HTTP API with
>> functionality at least equivalent to the existing API, with support for
>> reading from and writing to the OA serialisation devised in 1.
>> 4. Implement a storage component in Annotator which talks to this OA
>> storage API.
>> 5. Add support to Annotator for adding TextQuoteSelector to
>> annotations. This doesn't have to include using this selector to
>> reanchor annotations, although obviously that would be nice to have
>> If anyone thinks I've left anything essential out, please reply on-list.
>> Notably, Gerben has already made a start towards 1 and 3 here:
>> If we could bring any further discussion of the serialisation onto this
>> list, that would probably make it easier to track the discussion.
>> I'll also send round some links a little later with a suggestion of
>> where and how we would get started on 2, 4, and 5.
>> : http://www.openannotation.org/spec/core/
>> : https://github.com/openannotation/annotator-store/
>> annotator-dev mailing list
>> annotator-dev at lists.okfn.org
>> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the annotator-dev