Implement tagging in Annotator with realtime tag filtering

The Annotator software that we want to use for Open Ethnographer allows “free tagging” out of the box, and tagging with pre-existing tags using one of the following plugins (though we don’t know yet if any of these or maybe yet another plugin fit our needs):

The task is to add functionality to Annotator that allows

  • tagging with pre-existing tags
  • getting the tags handed over dynamically from a Drupal taxonomy vocabulary
  • a nice, fast client-side realtime search that filters tags based on what a user types into the tag search box; this is the main part actually

The idea is to have a very fast and user-friendly way to select pre-existing tags from a flat list (no tag hierarchies, yet). Different from the existing Annotator tagging interfaces, it should only be possible to add one tag per annotation. Because this simplifies the logic of “what tags (private or public) to show to whom” to “what annotations to show to whom”. It has no adverse side effects as selecting the same text again to tag it with another tag is handled gracefully by Annotator already, incl. viewing the multiple annotations on-hover and deleting any one of them with one click.

This is a paid task and welcome to be picked up by Edgeryders community members!

Implementation languages: JavaScript, HTML, CSS

Budget: 400 EUR for basic task, 200 EUR for add-on task of on-the-fly tag generation and syncing (see)

Collaboration: Delivery should be as a Github pull request to edgeryders/annotator. Payment is after your code was tested and integrated by @Matthias and after you have sent an invoice to Edgeryders. If there are bugs or later that prohibit basic functioning, you will have to fix them within the budget limits; if after payment, there are smaller bugs not affecting basic functioning (edge cases, nice-to-have features etc.) you don’t have to care.

annotation doesn’t store tags, but at least some of the code is there. Between that, drupal taxonomies, and jquery autocomplete, this shouldn’t be so bad.

1 Like

Oh, great

I’d have started with this task by now, but all the better if you want to take it on because then I can care instead to finally finish our notifications changes from the LOTE4 hackathon. Thanks for great collaboration so far :slight_smile:

If you run into unexpected problems: the budget is quite flexible on this task. We’d spend more on this if needed to get a great quality, since it’s the most often used piece of the user interface and thus worth the effort.

Great! First version is at; happy to spend time tweaking in response to feedback.

Currently the autocomplete is entirely client-side; that will probably give the fastest experience until we have a lot of tags (say, over 1000).

The UI also doesn’t currently prevent people from (a) using multiple tags, or (b) adding tags as they go.

1 Like

Nice, testing it after sleep

Looks good, though I did not test it yet (will do shortly).

1000 tags will not be reached, I think. At least not to be used simultaneously by one researcher (they might later select beforehand which set of tags to be able to use for current tagging jobs).

What I wonder now is, however: how can proper syncing of tags with Drupal taxonomies be ensured if it’s all client-side? I guess users’ ability to add tags on the fly currently is the free tagging in Annotator before, and there is not yet a synchronization with Drupal taxonomies. How’d you do it, on-save, or via AJAX? And, will these “new” tags be included in the auto-suggest when adding more taggings, without having to reload the page?

What I wonder now is

“What I wonder now is, however: how can proper syncing of tags with Drupal taxonomies be ensured if it’s all client-side”

You’re right; I’m just including a JS array of tags in the source, so the tag list only updates on page load. Would you like me to write in an ‘update the tag list’ callback, to be triggered when somebody creates a tag?


Thinking about it, I like how you implemented it so far, that one can add more tags “on the fly” by simply typing something as tag name that is not suggested by the auto-complete function. Would be the fastest way ever for adding codes, and I guess @Inga_Popovaite will like working with this feature (would you?). So, I suggest to keep this in. Consequences:

  • Yes, when somebody creates a tag (by using one not proposed by auto-complete), the JS array should be updated and the tag should be proposed by auto-complete from the next tagging on.
  • If somebody else (or the same researcher in a  second tab) creates a new public tag, this does not need to update the JS array immediately. Fine on next page load.
  • New tags created this way somehow have to be saved to Drupal taxonomy terms on page-save.
  • We do not need an additional tag-creation interface in the annotator_view sidebar, which was proposed originally. Nice, software's becoming ever more compact and intuitive :)

Paid, of course

Of course, if you want to take this and work out the on-the-fly tag creation and syncing to Drupal taxonomies, you will be paid with the budget from that task (which was originally meant to be done in the annotator_view sidebar). I’d propose an additional 200 EUR.

p2pValue and Drupal integration

Are you in contact with the guys at the p2pValue project? I talked to one of them at the 31C3 and they seem to be working on making annotator work properly, not sure if this means extending in the direction you want.

I am also particularly interested in a proper integration of annotator with Drupal. We wanted this for the Degrowth conference (allowing inline open peer review of the PDF papers, such as this one here), but unfortunately time was too short and we only managed to get a fully normal comment function on for biblio entries. However it is a much wished future for a future development of co-munity.

Do you work also together with the annotator module for drupal or are working on a parallel implementation? If it’s a similar implementation, it could be useful to merge efforts with the existing project.

Hi @gandhiano!

We are indeed building on top of the annotator module, and trying to figure out which of our modifications could sensibly be contributed upstream.

I personally haven’t had any contact with P2PValue. But it sounds as though it would be worthwhile to look into coordinating our work with them, or at least being aware of what they are up to. @matthias, @alberto, @nadia – are any of you in touch with p2pvalue?

1 Like


@danohu, p2pvalue at 31C3 was represented by Chris @Cataspanglish Pinchen, who used to be on the Edgeryders team in the olden Council of Europe days. So now you are in touch with him too. Small world, eh? :slight_smile:

1 Like


Hi all,

nice meeting up at #31C3 :wink:

I’m not on the technical team of P2Pvalue but there is an overview of what we are doing and how at

If anybody wants to beta-test, we have a mailing list for that: and anyone interested in testing the tool can subscribe in

We have also produced the new Wave API which allows to developers to build Web Apps with real-time editing capabilities in a decentralized architecture. Data shared across an organization can be edited and updated simultanously by people and also it can be shared and edited with people from other organizations using the same federated system - more at

Let me know if you want more info, or if you want me to put you in contact with devs…see y’all at FOSDEM?

THAT Wave?

“Wave” as in “Google Wave”?

now Apache Wave :wink:

1 Like

Relating the current work to PDF annotating

As @danohu said, yes we’re working with the Drupal annotator / annotation modules and would like to contribute back to their codebase. What I see as the biggest improvement so far is moving from pure URL + XPath based annotation anchors to those that identify the Drupal entity and use Xpath relative to the start of the node’s / comment’s text only. Means, synonymous URLs and template changes don’t invalidate annotations anymore. That change should find its way upstream …

Re. annotations for PDF, I see you use PDF.js. Adding XPath referenced annotations to PDF.js’s output runs the danger of invalidating annotations when teh PDF.js output rendering is changed on version updates. A workaround would be generating the PDF.js HTML5 output once and saving it as node content. But I think the true solution would be sequential word numbers, added to the output by a PDF.js option.

Random word IDs, as you see us talking about for Open Ethnographer, ain’t an option here as PDF.js would not the ones to use from last time. They are not needed either, as PDFs are not meant to change.

The interesting point is that in our annotator Drupal module rework, we probably should keep the door open for both options (sequential and random word IDs). You made your point still in time :slight_smile: and of course you’re welcome to contribute both ideas and code. We’re still in the budget, so if you can come up with a clever idea how to reuse the Open Ethnographer approach for what you need later, you can get paid for implementing it yourself.

It’s done!

As far as I can see, tagging and the Drupal taxonomy integration works flawlessly now, and so does the on-the-fly tag creation (which was added as an extension into this task, as per the discussion above).

Well done, @danohu. First major block done, and don’t forget to put this task on your invoice (400 EUR + 200 EUR) :wink: