Back in April, Audrey Watters’ decided to block annotation on her website. I understand why. When we project our identities online, our personal sites become extensions of our homes. To some online writers, annotation overlays can feel like graffiti. How can we respect their wishes while enabling conversations about their writing, particularly conversations that are intimately connected to the writing? At the New Media Consortium conference recently, I was finally able to meet Audrey in person, and we talked about how to balance these interests. Yesterday Audrey posted her thoughts about that conversation, and clarified a key point:
You can still annotate my work. Just not on my websites.
Exactly! To continue that conversation, I have annotated that post here, and transcluded my initial set of annotations below.
using an HTML meta tag to identify annotation preferences
This is just a back-of-the-napkin sketch of an idea, not a formal proposal.
I’m much less committed to having one canonical “place” for annotations than Hypothesis is
Hypothesis isn’t committed to that either. The whole point of the newly-minted web annotation standard is to enable an ecosystem of interoperable annotation clients and servers, analogous to comparable ecosystems of email and web clients and servers.
Hypothesis annotations of a PDF can be centralized, no matter where the article is hosted or whether it’s a local copy
Centralization and decentralization are slippery terms. I would rather say that Hypothesis can unify a set of annotations across a family of representations of the “same” work. Some members of that family might be HTML pages, others might be PDFs hosted on the web or kept locally.
It’s true that when Hypothesis is used to create and view such annotations, they are “centralized” in the Hypothesis service. But if someone else stands up an instance of Hypothesis, that becomes a separate pool of annotations. Likewise, we at Hypothesis have planned for, and expect to see, a world in which non-Hypothesis-based implementations of standard annotation capability will host still other separate pools of annotations.
So you might issue three different API queries — to Hypothesis, to a Hypothesis-based service, and to a non-Hypothesis-based service — for a PDF fingerprint or a DOI. Each of those services might or might not internally unify annotations across a family of “same” resources. If you were to then merge the results of those three queries, you’d be an annotation aggregator — the moral equivalent of what Radio UserLand, Technorati, and other blog aggregators did in the early blogosphere.
Annotation aggregator, reminds me a bit of the Elmcity Calendar Aggregator (which is STILL a great idea). And just as before, if someone can proselytize the standard APIs/formats and really encourage embracing the formats it will scale and make all the annotation collections usable for everyone. Fewer siloes and stovepipes, more hubs is a good thing.
One of my long-standing concerns about annotation capabilities for web pages – or anything hosted on the web – has been that a popular item could end up with annotations from hundreds or thousands of people, and even turn into comment threads. If that happened, the annotations would become virtually useless.
I haven’t figured out how to solve this problem yet, but I suppose in these early days it’s not too likely to happen.
One way to mitigate this problem is to segregate annotations into layers. With Hypothesis that happens when, for example, a teacher assigns the same document to students in multiple sections of a course. Each course can annotate in its own layer. More broadly, an annotation client can ask for annotations from multiple annotation services and present those as selectable layers.