Annotator Community Call Notes (7/16/13)
Attendees: Andrew Magliozzi, Nick Stenning, Anna Gerber, Kristof Csillag, Randall Leeds, Jamie Folsom, Dan Whaley, Eric
What's wrong now?
Nick’s annotator deck from Hypothes.is conference in April 2013: https://speakerdeck.com/nickstenning/okf-annotator-technical-overview#14
What’s done already?
Nick’s changes so far (7/16/13): https://github.com/okfn/annotator/compare/master...wip
- Mostly around the store plugin and serialization
- new annotation property: _local
- A local storage object
- should we leverage JSON.stringify()’s support of the toJSON method to make this automatic? Or too much magic?
What do we want to change?
UI decoupling
- Randall has some ideas and old code for this that may come in handy - suggests using DOM events
- Anna has a few concerns about custom UI as well - for complex UIs, events may need to be attached to different element than annotation target (especially when there are multiple Annotator instances on a page)
- Nick worries about relying entirely on DOM events, which would cause problems with programmatic or command line actions
- Ideally Annotator Core is simply a Database with the following calls:
- Create | Update | Delete | Query
ACTION: Randall to dig out highlighter extraction branch
Storage
- Currently the Store Plugin does everything
- Headers, Serialization, etc.
- Registry (added to Annotator repo on 6/25/13): https://github.com/okfn/annotator/blob/208498c36029b889e42b5c0734f6ef3485ea4954/src/registry.coffee
- We have two... er, three options
- 1) Advertise arbitrary meta-data to store plugins, which other plugins can add to
- Such as Headers
- 2) This is not the concern of the store plugin
- 3) Auth Plugin and Store Plugin should be combined (??)
Quorum Decision: Death of the Auth Plugin
ACTION: Nick to merge WIP branch
ACTION: Anna to test LoreStore with WIP branch
ACTION: Nick to merge Auth Plugin with new Store plugin
Flexible matching
Question: What happens if an annotation has multiple matches?
- Perhaps implement a ‘chain’ of matching plugins and ‘kill the chain’ if one finds a match
- Default is ‘range && x-path’ but you could also run a ‘matcher plugin’
- One matcher from the point of view of Annotator -- but, just like the store plugin could be a wrapper around multiple stores, the matcher could be a wrapper around multiple matchers. Default matcher: XPath lookup.
Hypothes.is has a working implementation of Fuzzy Matching...
- Goal: issue a pull request to implement that code in Annotator Core
- Question: How can we do this incrementally with test coverage and not breaking anything and remaining backward compatible with the existing reference store?
- Issue: Target v. Range in respective schemas...
ACTION: Kristof to extract Hypothes.is flexible matching and submit PR
Potential Solution: resolve DOM-specific matching and export the resulting matched range as a NormalizedRange in the _local object so UI can rely on the anchored range and be ignorant of the serialization
Consideration: Annotations of ‘other’ media types, such as images or videos. Jamie is curious about how to maintain ease of development for plugins that match annotations to non-textual objects.
- What must a developer do to make multimedia annotation possible?
- How can we make this as easy as possible for developers?
- A data model like this (deprecating ‘Ranges’) ‘targets’ are just ‘types’:
{
...
"targets": [
{"selectors": [{“type”: …}, {“type”: …}], ...},
{"selectors": [{“type”: …}], ...},
]
}
???
ACTION Anna: write up this discussion and send summary to mailing list
Interplugin communication more generally
Having plugins be usefully “pluggable” suggests that the plugins should be registered and retrieved by name rather than constructor. The store plugin is not `Annotator.Plugins.Store` but any object which implements the appropriate interface and registers itself as a ‘store’ plugin.
ACTION: Randall to remove all use of reference by class (use string names instead) in plugin instantiation/config.
Removal and idempotence
https://github.com/okfn/annotator/commit/cfbd11c903dc717eafc0cbeab5be800c3b5c7f1c
Other issues...
Release master as v1.2.8 and then merge WIP branch. If we need a v1.2.9 then hotfix from master pre WIP merge.
Ballpark time to accomplish everything above: ___ Days, ___ Weeks, ___ Months
ACTION Jamie to pull master (1.2.7) and build, integrate into a branch of Annotation Studio to test `Annotator#destroy()`
Proposals for improvement:
Plugin types
1. Generic plugins
Groups Plugin
- The best solution for this is on the DB layer by storing
Sets Plugin
1. Store plugins
2. Matcher plugins
Asynchrony
Other ideas...
Who can help? How? When?
Who is already working on these issues?
Sharing innovation upstream
Ownership, deliverables, & milestones
NEXT call: in one month...