[annotator-dev] To Web Annotation (from Annotator 2.x)

Thu Jul 30 21:10:08 UTC 2015

On Thu, Jul 30, 2015 at 3:53 PM, Ben Leinfelder <leinfelder at nceas.ucsb.edu>
wrote:

> I’ve been initializing the library on the <body> element so perhaps I
> haven’t encountered this particular limitation with relative xpaths.
> A while back, someone did a patch to the 1.2.x Annotator that would anchor
> the xpath at the nearest parent element with an id attribute. This is way
> better than the relative anchoring that you describe and even allows for
> some rearranging of the page layout over time if you have fine-grained
> elements with ids. It also allows you to initialize Annotator anywhere in
> the DOM (as long as it is “above” your first annotated element with an id
> attribute) and still find the xpath selections.
>

Yeah, this sounds similar to what Chrome gives you if you "Copy XPath" from
the Inspector. for instance:
```
//*[@id="aims-of-the-model"]/p[1]
```
from http://www.w3.org/TR/annotation-model/#fragment-selector

That would re-anchor if the DOM structure changed, but the ID lived one
somewhere in the document.

> My understanding was that the xpath was used in conjunction with the
> character range selector such that within p[1] you have selected the 50-56
> characters which are “netus”.
> It seems like you do need both xpath and character selectors to
> unambiguously find a range, but the quote just lets you verify that
> selection.
>

So...you're right...I (rashly) assumed this was within document
"space"...which means my Annotator-to-Web Annotation implementation is less
"done" than I'd hoped since now only the TextQuoteSelector is of any real
value. T_T

Bother...

>
> I could also be totally misinterpreting how things work in AnnotatorJS :)
>

Apparently, the current Annotator will have to be augmented to work inside
an "Open World Assumption." The data it's storing is really only meant for
itself, and even that with relatively little shift in what it's annotating.

Likely, fixing that looks like a handful of suggested plugins, and
eventually improving what Annotator stores, so that data can have value for
others.

We'll get there! ;)

Thanks for the help, Ben!
Benjamin
--
Developer Advocate
http://hypothes.is/

> -ben
>
>
> > On Jul 30, 2015, at 12:28 PM, Benjamin Young <bigbluehat at hypothes.is>
> wrote:
> >
> > On Thu, Jul 30, 2015 at 12:51 PM, Ben Leinfelder <
> leinfelder at nceas.ucsb.edu> wrote:
> > I’m more familiar with the Open Annotation model and RDF than I am with
> this Web Annotation model and JSON-LD direction (news to me today, in
> fact). But they seem conceptually interchangeable.
> >
> > Not much has changed (afaik) to Open Annotation in it's journey to
> become Web Annotation. The addition of the JSON-LD @context and those
> examples (as primary!) in the spec would be the biggest changes that I know
> of. The "meta model" is the same, however.
> >
> > So, likely it's still familiar territory for you. :)
> >
> >
> > The XPath-y selectors could be added to your model using
> oa:FragmentSelector and some #xpointer(/my/path/to/something) value.
> > http://www.openannotation.org/spec/core/specific.html#FragmentSelector
> > I agree that the model is lacking when the quote of an annotation spans
> different elements and may require an additional property to specify which
> of (potentially multiple) oa:FragmentSelectors should be used for the start
> and end of the selection.
> >
> > So, "XPath-y" is the right word here. ;)
> >
> > Annotator stores partial XPointer's (technically, I suppose) relative to
> the element that annotator is listening inside of--which means, they're
> pretty much worthless if you don't know which element Annotator was
> connected to when the XPointer was generated.
> >
> > For example, in the Annotator JSON that's part of this little To Web
> Annotation project there are two keys inside `ranges[0]` (`start` and
> `end`) which store XPointers. In the example...they have the same value
> `/p[1]`.
> >
> https://github.com/BigBlueHat/to-web-annotation/blob/master/index.html#L38-L41
> >
> > Annotator isn't using XPointer as a way to identify *the* selection, but
> only as an optimization (afaik) to get closer to the DOM node which
> contains the selection.
> >
> > As such, those XPointers don't have much use to others (besides the
> current implementer), because:
> > 1. you have to know the parent element Annotator is annotating "inside"
> of
> > 2. even if you know that, they don't actually give you the selection
> that was made...just it's parent node
> >
> > Having those is useful for Annotator performance, but not (as I'd hoped)
> universal data value...at least not without changing Annotator--which is
> fine. ;)
> >
> > I'm planning on floating this XPointer thing past the W3C Annotation
> Working Group, and see if I've got the encoding right in the example I'll
> include. If I do, then it's back to Annotator to see what I can fix without
> breaking anything. ;)
> >
> > Thanks for the thoughts, Ben!
> > Benjamin
> >
> >
> >
> >
> >
> > Have you tried shoehorning the into/out of oa:FragmentSelectors?
> > -ben
> >
> > > On Jul 30, 2015, at 9:25 AM, Benjamin Young <bigbluehat at hypothes.is>
> wrote:
> > >
> > > On Thu, Jul 30, 2015 at 11:23 AM, Ben Leinfelder <
> leinfelder at nceas.ucsb.edu> wrote:
> > > Hi Benjamin,
> > > I haven’t been following 2.x development closely, but I thought
> supporting an Open Annotation model natively was on the TODO list for
> AnnotatorJS.
> > > Sure enough, the road map lists it -
> http://docs.annotatorjs.org/en/latest/roadmap.html
> > >         - Internal data model consistent with Open Annotation
> > >         - A (beta-quality) storage component that speaks OA JSON-LD
> > >
> > > Pretty sure that got pushed back to target a later release though that
> decision is not yet reflected in the roadmap. Getting Open/Web annotation
> models from AnnotatorJS is one of the features I really really want from
> 2.x, so I’m wondering how your plugin conversion work relates to the goals
> on the 2.x roadmap?
> > >
> > > It's that goal done as a plugin, basically. :)
> > >
> > > I actually extracted the conversion code from this storage plugin
> project:
> > > https://github.com/bigbluehat/annotator-pouchdb/tree/web-annotation
> > >
> > > PouchDB (and CouchDB) are "just" JSON document stores with no JSON-LD
> "smarts" (without extension anyhow). However, you can see from that code
> that the plugin is basically just running the conversion during storage and
> retrieval...nothing more.
> > >
> > > In theory, if this piece can indeed be made to be this common, it
> could be hooked into a storage plugin (as I've done) or put in as it's own
> plugin that converts the annotations whenever they're JSON'd.
> > >
> > > One thing to note from this is that Annotator 2.0's model is nearly
> compatible already with Web Annotation.
> > >
> > > The one piece un-expressable (so far) is the XPath ranges--which is
> work needed on the W3C Working Group's end...which is also on my list to
> ask about. ;)
> > >
> > > If you've got experience with Open/Web Annotation Data Model, I'd
> *love* help on this project. Especially if you've got experience with a
> "smarter" JSON-LD-loving storage provider, so we can see if this "un-smart"
> conversion at storage time thing could actually provide what's necessary.
> > >
> > > Any and all thoughts are welcome. :)
> > >
> > > Cheers!
> > > Benjamin
> > > --
> > > Developer Advocate
> > > http://hypothes.is/
> > >
> > >
> > > Thanks,
> > > -ben
> > >
> > >
> > > > On Jul 30, 2015, at 7:54 AM, Benjamin Young <bigbluehat at hypothes.is>
> wrote:
> > > >
> > > > I've been working on some (deliberately very) basic conversion code
> to turn Annotator 2.x JSON output into Web Annotation Data Model.
> > > >
> > > > Here's what I've got so far:
> > > >
> > > > http://bigbluehat.github.io/to-web-annotation/
> > > >
> > > >
> > > > Code lives at:
> > > >
> > > > https://github.com/BigBlueHat/to-web-annotation
> > > > The hope is to build the SimplestThingThatCouldPossiblyWork to move
> Annotator JSON docs into the wide world of Web Annotation.
> > > >
> > > > I've posted more JSON-LD related thoughts to the W3C list (which is
> public for anyone to join FYI!):
> > > >
> https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0225.html
> > > >
> > > > It'd be great to hear thoughts on this project and approach from the
> Annotator side.
> > > >
> > > > The slightly longer term objective is to make this conversion (once
> I'm sure it's correct/working well) available as an Annotator plugin for
> use with storage providers that "speak" Web Annotation.
> > > >
> > > > Feedback welcome!
> > > > Benjamin
> > > > --
> > > > Developer Advocate
> > > > http://hypothes.is/
> > > > _______________________________________________
> > > > 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
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20150730/5a905e08/attachment-0004.html>