NISO/IA Meeting in San Francisco
Several people have already posted extensive notes about this meeting. Among them I recommend reading +Peter Brantley
article in PW (http://blogs.publishersweekly.com/blogs/PWxyz/?p=7780
), +marc jahjah
for an excellent analysis (in French, but worth translating for anyone) based on the tweets that were published during the meeting (http://www.sobookonline.fr/livre-enrichi-social-interactif/livre-social/books-in-browsers-annotations-et-lecture-sociale/
) along with the EtherPad that was shared by the attendees (http://ietherpad.com/ep/pad/view/ro.cpCnwYD9oW6/rev.769
While a similar meeting was also organized during the Frankfurt Book Fair, it seems that the SF meeting was overall much more technical, and the round table organized at the end of the day was a good way to kickstart the project.
For this post, I'd like to focus on these discussions and provide an overview of the things we discussed and decided during this round table.Scope
Many issues were raised during the first half of the day. Among other things, to have a fully standard way of sharing annotations we would need to deal with:
- a way to point precisely in the text
- a standard model (OAC ?)
- metadata associated to the annotation
- a serialization format
- an exchange protocol
- privacy issues
- copyright issues
- identifiers for the publications
... and this list could go on and on forever.
In order to be as pragmatic as possible about what we should do first, we raised hands to vote and decide what the most pressing issue would be. A vast majority voted for the pointers/locators. If we can't associate an annotation to its original text, what's the point of working on anything else ?Strong/Weak Linking
During his presentation, +Bill McCoy
(IDPF) mentioned that one of the things that the EPUB3 Working Group identified while working on annotations was the need for two types of links between an annotation and its source:
- a strong link
that will point very precisely in a text but might easily break if the source is modified
- a weak link
(also called a fuzzy link) that won't point as precisely in a text but should be less affected by potential updates
While the EPUB3 WG didn't completely solved this problem, and struggled with a good way to group/package this information together, a strong linking specification was still published under the name of Canonical Fragment Identifier (http://idpf.org/epub/linking/cfi/epub-cfi.html
Unlike similar specifications (XPath, Xpointer), CFI solves a few problems that are specific to an EPUB publication (such as pointing to the right file in the container, and not just the right XML element and character).Context is essential
During our debates, Aaaron Miller (ReadSocial) insisted several times that context is essential.
If we create annotations and link them back to the text strictly with a strong link, such annotations would be almost useless without the original source.
On the other hand, if the annotation includes additional information that would also be relevant to a human (such as the highlighted text or the position in the book), these annotations could easily be displayed and used on their own.
Services such as ReadMill or Findings are entirely built on such annotations.No perfect solution, the right one is a mix of strong/weak linking
Luckily, what we call context
here seems very similar to the idea of a weak link
. Not only would this information allow third-party services to add value to these annotations, but they would also be potentially less prone to turn into orphans as the text is updated.
Since there is no perfect way to link an annotation to its source, the right solution would be a mix of strong/weak links. We must also realize that even with such a combination, an annotation could still turn into an orphan if the text is heavily updated, which means that context is even more essential. We need context to make such annotations useful on their own, even when they can't be linked back to their original source.Strong link ?
While CFI was the only strong linking solution officially presented during the day, everyone around the table used something equivalent.
Some of them were counting paragraphs and then characters (which is clearly limited since we could also annotate a video or an image thanks to media fragments), others relied on DOM Selectors, XPath or even their own ways of selecting an XML element and then down to the character level.
It'll take some time and efforts for everyone to agree on the right solution and we might need to allow several options. The following requirements have been identified so far:
- we need to be able to sort these links easily
- we need to select an XML document in a package (CFI for EPUB is an example of this need)
- we need to be able to select any element in an XML tree and not just paragraphs (annotations on an image, video, audio file)
- we need to have character level precision in text
- for other media we can adopt the Media Fragments URI 1.0 (http://www.w3.org/TR/media-frags/
- the spatial dimension (from Media Fragments URI 1.0) need to be extended to support non-rectangular shapesWeak link ?
Aside from providing a better context, everyone around the table also used one or more weak links to improve the accuracy of their annotations. Such links were not strictly used for context, everyone agreed that using them with different heuristics clearly helped, and a few services even mentioned that with the same annotation/links they managed to improve accuracy over time.
These links were all either positions or text strings.
For the position, everyone either used a character count (seems very fragile to me without a total character count too) or a % (which would be equivalent if this is provided with a long float).
Rules would need to be clearly defined for both. Do you count blank characters too ? Do you count XML elements as characters ? Would a total character count provide more information than a % (could be an indication that the text has been updated) ?
For text, everyone had their own rules too. It seems that most of them stored the highlighted text, but many services also stored text before and after the highlighted portion.
Processing rules were also different between services. What would be the ideal length of the stored text before/after the highlight ? How do you deal with blank characters ? Is it better to have an offset rather than the text right before/after the highlight ?
All of these questions need to be answered before we can rely on this information for something more than context, but overall these were mostly details and all agreed on the major points.Other links and a container
Aside from these examples, a few domain specific publishers raised an interesting point: for some publications such as the Bible, legal documents or scientific papers, other units exist as a standard way to reference the source document.
We'll need to provide basic extensibility to allow these specific references.
Since we'll need several links and various metadata to create an annotation, a container is also an absolute requirement. Even if we don't tackle issues like a protocol for annotation sharing, we do need to define a few rules on how this container and these core links/locators (which concepts/words should we adopt ?) should be serialized.Moving forward
We're only getting started, and it'll take time and effort to tackle and solve all of the various points that we raised (see the scope section of this document).
If we can agree on how we link annotations to their source though, we'll have the most important requirement solved. The real work
will start on January, when the working group is officially launched. In the meantime, we could make a real step forward if each service documented its own links/locators (the IDPF went through a similar step before the Taiwan meeting about Fixed Layout, see http://code.google.com/p/epub-revision/wiki/TaipeiFixedLayoutWorkshop