Yes but …
Glad you like Annotator. Basically this, our own tagging plugin for Annotator, annotator_view and search integration, and we have the basic Open Ethnographer thing together.
And yes right, one can configure which element Annotator should start from. But it only affects where an annotator button will be shown when selecting text. The annotation will still get stored with the full XPath starting from the document root. For example, in my case Annotator is configured to only allow annotations for the .node element and below, but a path stored with that setting is /div[1]/div[3]/div[1]/div[1]/p[1]. Changing anything about the node template would break it. Or anything about the URL, since it does not (yet) use the Drupal canonical URLs (/node/id). So yes, we need to rework it …
Since annotation ranges are simply stored with XPath expressions, the simplest thing would be to use those adapted for word IDs (//span[@id=‘w-7x64shgw’) or, if we don’t want that, at least those starting from the content elememts’ enclosing tag. These are already nicely marked by Drupal, so we can use for example //[@id=‘node-2345’]/p[3] or //[@id=‘comment-12345’]/p[3]. Should work, but I have to test still … . And, it would still be a hack. The clean solution is adding “entity type” (node, comment etc.) and “entity ID” columns to the annotation database table. Annotator would get these IDs from the HTML IDs shown above though – I think there’s no other way.
Another aspect of the reworking is to store tags, which is possible with some patches apparently. For marking annotations as public (“shared”) or private, we should look to the Authentication and Permissions plugins of Annotator. Or maybe not, as the public / private info should concern whole tags / codes, not individual annotations.
I have rethought the word ID tagging. Storing annotations as (word ID, tag ID) tuples would work, but creates some problems: Annotator will expect connecting subsequent words that are annotated with the same tag into the same annotation. The same for search result snippets in the quotation manager. Also, the storage would more be like (word ID, tag ID, user ID, created date), so contain quite some redundant stuff that is be shared by several annotated words the way Annotator stores it now. So: we could keep with how Annotator does it now (with the above XPath related changes). And then later, when wanting to make Open Ethnographer change resistant, store the annotated text as both a string (like Annotator does now) and a list of word IDs (in addition). Then, have a function hooking into node saving that adapts all annotations on the node based on the word IDs stored with the annotation. Since we use word IDs only to reposition an annotation, making them an optional add-on, we have some chance to get this added to the annotation Drupal module.
Annotations on changing content is a major unsolved issue for Annotator (see here and here), and they intend to solve it with heuristic repositioning and manual confirmation. Open Ethnographer has the advantage that we can control the text and add word IDs, allowing for a deterministic solution. But as said, we can develop it lateron with this new proposal.
As always, welcome to pick this up if you want, 