[annotator-dev] Open Annotation support in Annotator

Tue Oct 7 23:37:53 UTC 2014

There was discussion towards 1 here:
https://lists.okfn.org/pipermail/annotator-dev/2014-June/000979.html

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
work)

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
response!

Rob

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[1] 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
> oa:Annotation.
>
> 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[2]) 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[3] in Annotator which talks to this OA
> storage API.
>
> 5. Add support to Annotator for adding TextQuoteSelector[4] to
> annotations. This doesn't have to include using this selector to
> reanchor annotations, although obviously that would be nice to have
> soon.
>
> ---
>
> 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:
>
>     https://github.com/openannotation/annotator-store/pull/83
>     https://github.com/openannotation/annotator-store/pull/90
>
> 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.
>
> Best,
> Nick
>
> [1]: http://www.openannotation.org/spec/core/
> [2]: https://github.com/openannotation/annotator-store/
> [3]:
> https://github.com/openannotation/annotator/blob/6581f25/src/storage.coffee
> [4]:
> http://www.openannotation.org/spec/core/specific.html#TextQuoteSelector
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20141007/8629e59e/attachment-0004.html>