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 <bigblue...@hypothes.is> wrote: > > On Thu, Jul 30, 2015 at 12:51 PM, Ben Leinfelder <leinfel...@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 <bigblue...@hypothes.is> wrote: > > > > On Thu, Jul 30, 2015 at 11:23 AM, Ben Leinfelder > > <leinfel...@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 <bigblue...@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@lists.okfn.org > > > https://lists.okfn.org/mailman/listinfo/annotator-dev > > > Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev > > > > > > _______________________________________________ annotator-dev mailing list annotator-dev@lists.okfn.org https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
