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

Thu Jul 30 19:53:44 UTC 2015

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. 

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.

I could also be totally misinterpreting how things work in AnnotatorJS :)
-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
> >
> >
> 
> 