Transcription
[Digital music]
[Applause]
Lyza Danger Gardner: Well, hello, everybody. I am super happy to be here, slightly dazed. Beautiful space. Hope we get along well together. Let’s do this thing.
I’m Lyza. I am terrifically fond of the World Wide Web, what it represents, and what you can do with it. I also have a thing for Web standards, whether that is admiring them from afar, building software on top of them, or finding bugs in browser implementations. I’m a developer at a company called Hypothesis, which is a nonprofit company that builds open source software to support Web annotations.
Using the Hypothesis browser-based client, you can highlight, select text, and make an annotation basically on any Web page. So, people have been annotating things for millennia to annotate, from the Latin anotare, meaning to mark, to add notes, explanations, expansions, or sketches, what have you, to a document, diagram, image. And, despite the traditional practice of making these marks, often on the target document itself, annotations really do exist on their own. They are not part of the document’s content but, instead, form a valuable set of related meta content.
So, Web annotation defines a way for users, the worldwide, to make annotations about documents on the Web. And, maybe you’ve heard of it, and maybe you haven’t. Either way is fine. But, yes, actually, Web annotation is, as of 2017, an actual W3C standard. It defines a way for people to add metadata and relationships between Web resources, representing annotations, effectively allowing for a conversation layer on the Web.
So, working on a team implementing the Hypothesis Web annotation software, as well as getting to know the specs in great depth--and, yes, I read the specs. So, yes, I also agree that reading specs is a pretty good way of figuring things out--it’s been making me reflect a lot lately. And, watching Web annotations face the same joys and tribulations as I remember seeing over the many decades of the Web itself, other Web standards, the Web as a whole. And, the many things you can do with Web annotation are really quite intriguing. But, like the journey of other standards and the Web as a whole, it’s a bumpy road, and Web annotation has got its fair share of challenges, to be sure.
Speaking of journeys, on today’s journey what we’re going to be doing is traveling across different scales, zooming way out to see the themes of the Web universe, but also zooming in to learn about how Web annotations work within that universe. We’ll see how it connects, how a Web annotation’s journey is like a miniature microcosm of the Web’s own journey itself. So, we’re going to start zoomed way out, looking at the Web itself, which millions and billions of people use every day and, for us, it’s the stuff of our everyday reality, day in and day out.
But, if someone actually handed you a crayon, a pencil, or a pen and asked you draw the Web, what would you end up with? Would you have a cloud, a spiderweb, a bunch of hastily sketched servers on the back of a napkin? The point being the Web is a furiously abstract concept. But, despite that, I think we actually hold a shared core understanding of it. We have a picture in our mind that is rather shared - a collective concept.
The classical Greek philosopher Plato explored the difference between how we conceive of something versus how it manifests in the real world. His theory of forms proposes that the true existence of any given thing is actually in a separate, more ideal realm that is completely inaccessible to us, mere mortals. In the context of something far simpler than the Web, like a chair, Plato would argue that all chairs we see around us are really pale shadows of the one true chair, which exists as a pure, archetypal form in that inaccessible, pure realm. We can only create approximate chairs in our more pedestrian, inaccurate reality, but that’s okay because those imperfect echoes of the pure chair are collectively understood between us such that we know that, in fact, in our reality, this is a chair, and this is a chair, and this is also a chair. They all share chair-ness, which we recognize inherently.
Likewise, with the Web, I believe that there is a Web-ness. That we recognize patterns that feel concordant with the Web despite the noise and details that differ between our exact individual experiences on the Web. That is, for all of the vague things that are the Web, there are common attributes and themes of a shared Web universe that we work with every day.
The Web is our universe. It’s vast in scale, but with certain rules and consistencies that, when broken, tend to bug us. It expands and evolves and usually manages to self-correct as it goes, but it’s chaotic. We may not be able to easily draw it, but we carry a sense of it in our minds.
To be sure, these foundational essences do include core technologies and elemental standards like HTTP, TTP/IP, and HTML. But, they’re anchored by a system of connectedness and linked entities. The Web is, above all, about connections between things.
The Web has a feel that we know when we see, even if it is vague. Builder of the Web Jeremey Keith had a blog post several years ago in which he described the difference between a technology that was built of the Web versus merely being extant on the Web. You can feel it. The Web has a cohesion of principle.
The Web is so many things; what we make it into. It’s noble and it’s practical. It’s ours. We feel an ownership and a responsibility for its success. It’s brilliant, but it is also flawed.
The Web means democracy but, in that, it means lack of control. The Web moves too slowly. The Web is too broad and abstract. The Web is beset by security challenges. It is a vast, imperfect universe, but it is ours. There are bright stars, and there are black holes.
These recurring thematic tensions are playing out and have been playing out over the decades of the Web’s existence, and so in miniature and smaller scale with the Web annotation standard, the technology we will be examining today. We will get there.
Let’s start navigating a bit just in toward our Web annotation destination. At this scale, we can see the galaxies of linked connectivity created by linked data on the Web. The entities of the Web don’t exist in isolation all by themselves, isolated and lonely in the cosmos. Or, at least, they’re a lot more useful if they’re not isolated.
The Web has layers, fields of interconnectivity overlaid on itself like star maps, graphing connections between entities in different contexts. Hyperlinks are an obvious example, and they connect Web documents, which are located at URIs. Humans can explore this connectivity, this Web, if you will, as they browse the Web and make their own paths through this massive data graph.
But, there are many, many more kinds of useful relationships between entities than linking documents to each other, the kind of relationships that could be read and understood, not just by the humans on the Web, but by the machines that are helping humans do their useful things on the Web. The kind of relationships that can be read and navigated, again, might involve relationships between people, between places, or books, or different kinds of dinosaurs.
Let’s say you have two people, that is, data representing two people, and there is a connection between those two people. These entities or objects which are still identified by that Web cornerstone, the URI, can be connected to each other through relationships such that we could say person A knows person B. Entities identified by URIs connected through relationships, like this person wrote that book or, perhaps, that this dinosaur eats this other dinosaur. And, I recently learned that tyrannosaurus rex may actually be cannibalistic, which really freaked me out. They actually eat each other, so how about that? That’s an interesting relationship.
But, anyway, this model, in which URI identified objects are connected to other URI identified objects through relationships, is called link data and adds to the interconnectivity and usefulness of the Web as a whole. Connecting up those individual bits of star-like data into constellations and galaxies. For this to work, for us to be able to pull together isolated entities on the Web, to make such layers as annotation possible, we need structured and interoperable vocabularies, formats, and protocols for expressing and exchanging this kind of data connecting things together.
One way to structure linked data is through RDF, resource description framework, a metadata model that could be understood by the various computers looking at it. RDF is a framework for expressing that linked data in which objects are, again, related to each other. In RDF terminology, the linked information is expressed with something called an RDF triple, which relates a subject to an object through a predicate relationship, sometimes called a property. Slightly different terms, but the same concept of relationships between objects and entities. We don’t need to dive deeply into RDF specifics, but it’s helpful to know that RDF does serve as a backbone for the other types of linked data we’ll talk about today.
The subjects and objects in RDF triples are the nodes in the data graph while the predicate or property connects them, which is a concept that makes general sense, but how does that apply in real life? Well, you take a look at a bit of HTML. As a human being, you can spot that this is about a person. There’s my name. I do love talking about myself. And an email. It sounds like, you know, attributes of a human being.
But, without more context or structure to that markup, that data is lost to computers that are looking at the Internet. Now, this is something RDF could help with. But, if we want to do that, then we need some way to express RDF within the HTML itself, and we can do that by using an extension to the HTML standard called RDFa. The A stands for attributes because it extends HTML with a series of attributes that can be useful for expressing linked data.
So, we go back to the HTML snippet here. We can enhance the markup using RDFa attributes to connect this to the linked data Web. The first step is to determine the context that this data actually fits into, like, what is this thing? So, in this case, I’m going to go ahead and decorate this HTML to give it structured meaning per the FOAF vocabulary, which stands for “friend of a friend.” It’s the vocabulary for people and their relationships that’s been around for quite some time. We’re going to use this as our context.
So, if we go back to our HTML snippet here, we can go ahead and start telling it what we’re doing with it. So, we’ve got a vocab attribute here, a property here that will express that this element and its children are associated with that FOAF vocabulary that is identified by that UI there. And, we tell it that we’re talking about a person type of object.
People have properties like names defined in the FOAF vocabulary. Now, this HTML snippet is marked up, is decorated, and has a context and meaning in the linked data Web. So, RDFa allows for the expression of RDFs within HTML, which is an important document format on the Web, to be sure. But, for data exchange, the Web is certainly coalesced around JSON, JavaScript Object Notation, that familiar format of attribute value pairs.
Isolated bits of JSON, again, while perhaps human readable, are just that - isolated. So, sure, you can often figure out what data should be by looking at it as a human being, like here we kind of have a person again. But, once again, to connect it together, to bring it into the linked data Web, we need to give it some context, to give it some glue. And, this can be done using JSON-LD, an extension to JSON that makes it possible to encode linked data. It makes it possible for a JSON document to be valid RDF.
We can take this previously isolated JSON and entirely reconstruct it in JSON-LD, which is a little bit more complicated looking, but what’s going on here is we’re giving it a context, just like we did in RDFa in our HTML. We’re pointing it at FOAF saying this is our context; this is what the data in this is going to mean. We have, again, a person type. And, once again, there’s a name property. There are a whole lot more properties, of course, you could express with FOAF, but I was trying to keep things a little bit simple here. So, analogously, RDFa, which allows you to express RDF in HTML, while JSON-LD allows you to express RDF in JSON.
So, the Web is a set of related and linked things that are organized so that they can be read by people and the machines that are helping them get things done. It is the desire to connect more of these things in more ways and interact with these interrelated things that drives much of the evolution of the Web. So, let’s back up a bit again and talk about how we got here and actually chart our journey toward how we’re going to get to the point where Web annotations become relevant.
Back in 2004, 2005, we were presented with a bold, new thing, Web 2.0. We were told that suddenly the Web was no longer read-only and that we were all empowered to be participants. We can tag photos and use in-browser applications and all that stuff you’re used to.
Much of this road the wave of the XHR Ajax revolution, to be sure. This was the read/write Web. It was the participatory Web, and it was good. But, really this shift towards a world writable Web wasn’t a totally new idea at that time.
As far back as the mosaic and very early Netscape days, Marc Andreessen was pushing for annotation as part of the earliest Web browsers. That is, Andreessen saw annotation as central to what the Web browser should be. It didn’t work out, however, because the technology just wasn’t there at the time. Engineering and performance challenges abounded.
But, from the Web’s very outset, there’s been this kernel of desire for this wide-open ability for anyone on the Web to be able to do this kind of thing. And, it’s not that others didn’t try in the ‘90s and early 2000s. A browser plugin that allowed any user to add stick notes to Web pages, called Third Voice, was released in the late ‘90s. It didn’t go well. With no restrictions or protections against spam, the service startled content publishers who felt out of control and under attack. Hundreds of Web hosts got together to fight the service, which folded in 2001.
Nor was lack of success reserves for proprietary services like Third Voice. The W3C entered the fray around 2001-ish with Annotea, which arose along with the rising trend of the semantic Web. This was the early heyday of RDF, and Annotea was all about expressing annotation data in RDF. The problem was, no one used it and it faded again into obscurity.
Google’s 2009 Sidewiki project only lasted until 2011, but it was around this time that efforts at standardization really kicked into gear. Open annotation collaboration and the separate but also difficultly named Annotation Ontology Group kicked up in 2009, following in around 2011 by a W3C community group and, by 2014, a so-called “real” Web annotation working group, which means it was working towards an actual standard at this point.
In 2017, Web annotation was standardized, and the outputs of a W3C working group working towards Web standards are something called technical reports, abbreviated as TRs. For Web annotation, there are three component TRs: the standard is composed of the Web annotation model, which defines what the actual -- what an annotation is; the Web annotation vocabulary, which defines how to express things about Web annotations; and a Web annotation protocol, which gives some guidance on how annotations should be exchanged, across systems especially.
The working group had a number of objectives when they were working on the standards. The goal included -- their goals included interoperability, really centering around the URIs, a real touchstone. They designed the model to be orthogonal to the domain of interest, which is sort of a fusty way of saying that it should be all things to all people. So, it tends to be more abstract than focused on how it’s going to be used. And, they also wanted to make it simple and inexpensive to implement, unopinionated about particular technologies.
All right, so we have done enough history, and now we can zoom in a little bit more and see actually what annotations are and how they work. So, there’s a fully baked standard. Hooray!
But, wait a minute. What is an annotation, actually? What are we -- what is this thing we’re talking about?
I hope you’re ready because here’s the amazing definition: It’s a set of connected resources typically including a body and the target where the body is related to the target.
Awesome. Okay. Pretty open there, so maybe a little bit of a letdown considering how long I’ve let up to it, and typical of Web standards to be rather abstract and genetic. But, let’s get into this a bit because, like all linked data, an annotation expresses relationships.
Every annotation has a target, an external Web resource identified by a URI. The annotation itself must also have its own URI. URIs everywhere, right?
Now, what we have, at a minimum, is a relationship between an annotation container and a target identified by a URI. That simple starting point is enough to define annotations that behave kind of like bookmarks, basically, just annotation pointing at a target. In some cases, this may be basically it. An annotation that indeed simply points at a target could be used to, say, bookmark a Web page like this inferring article about startling discoveries in the T-Rex diet that suggests they might be cannibals. But, to actually annotate something in the fuller sense, the annotation is going to need a body, something to hold the notes or comments or whatever you’re creating that relates to the target.
An annotation’s body may be as simple as some text-only notes written by the annotation’s creator about that target. Like my expression and surprise and dismay about this article about T-Rexes. They may have been cannibals. I still am bothered by that. So, of course, my annotation body, a personal expression, isn’t very useful to the wider Web community, but it’ll do as an example here so that we can start to get a peek at the underside of a simple annotation and how this would be serialized in JSON-LD.
The earlier JSON-LD example we saw defined a context that was the FOAF vocabulary. But here, we’re talking about Web annotations, so we point at the Web annotation one. It has to have an ID. That’s a URI. And, because we’re just doing a simple string, we can use a property called “bodyvalue” and just stuff that string right in there. And, the target, again, a URI, the target of this relationship, so that’s that article.
This is of some use so far. One could make some basic notes about Web pages or bookmark them, but it’s mainly a starting point. Annotations are flexible and have a bunch more to them.
As a human making notes about the things I see on the Internet, I have a tendency to want more than just plain text strings in my annotation bodies. I need to emphasize that this article is really wrong. It just can’t be possible.
We can make a more sophisticated body for the annotation. By using particular type, like bringing it up into an actual object, and by using a particular type of body, I can go ahead and put my formatted HTML right in here because I’m also going to denote that the format of this body in this annotation is HTML.
And, with annotations, we say that the annotation has a relationship to a body, and that’s true. But, in our first example, while the body is certainly still a relationship to the annotation, it’s defined right within the annotation’s data itself. But, bodies don’t have to exist within the annotation. They can be completely separate, external Web resources.
So, let’s say I made a rambling, somewhat incomprehensive video about T-Rexes in which I, in part, refute the content of the article about T-Rexes and what they eat. We can make an annotation that actually references that video as a body. Again, we could just, in our body, instead of having the body content right here, it has an ID, again a URI. That’s where you can find it, and it happens to be a video, so we’ll give you that hint as well.
So, we’re looking at a lot of JSON-LD examples, but the specifics aren’t super important. What I’m trying to get across is about how much there is the Web annotation model and how much flexibility it gives you in its relationships and properties. The annotations are quite flexible. They can do things like capture the why, the motivation of why this annotation was created in the first place, including such things as bookmarking or commenting or moderating.
In the case of my video refuting the cannibalistic behavior of T-Rexes, perhaps the motivation is that of questioning, for asking questions about the target or actually questioning its veracity overall. And, there you have it. All right. So, this goes on and on. I’m going to stop at the tip of the iceberg, but there are other properties about who created it, when it was last modified, who the intended audience is, what kind of licensing rights are involved. The point being, there’s a lot here, including a fair number of things that give us the ability to refine and hone the meeting and the scope of an annotation even further.
Perhaps it has already occurred to you that sometimes you want to annotate content that is much more fine-grained than an entire Web page, right? Instead of annotating the entire T-Rex article’s Web page, perhaps my annotation only relates to a subsection of the article. So, Web annotation data model provides a number of ways to give hints and define and refine target or body resources beyond what a URI might be able to specify on its own.
These selectors allow you to define resources segments that are relevant to the annotations. URI fragments are one somewhat evident tactic for defining more granular targets. Assuming the T-Rex diet page has elements with IDs that allow the formation of fragment URLs, you can do something roughly like this where we add a selector into our target of a fragment selector, and we give it a value of the fragment we want. And, it puts together the fragmented relationship that helps the annotation zoom in on where it’s applicable to. So, that refines it to the new theories fragment.
But, there’s this other little side note fragment -- I’m sorry -- properly right here it conforms to. What’s that all about? This is just extra information because I was, like, oh, there’s a property in there that I didn’t define, so I should tell you. But, for the curious, fragments are not constrained to just HTML documents. For example, SVGs, PDFs, CSVs, and other media types have their own ways of creating fragments. They have different semantics, however, and the fragment semantics or syntax for those different media types are defined in a bunch of different RFCs in the standard, so it just points at their relevant standard. So, that’s your little sidetrack for the day.
But anyway, still, that is not enough if you want to highlight at something that can’t be URI accessed, right? If you’ve got, like, a sentence or paragraph on a Web page and you want to add an annotation about that, like, how do you do that, define it, and make that definition something that can live and be accurate as the page changes over time or the document changes over time? You can do that by actually combining several different selectors at once, as many as you want. There are many different types.
I’ll just touch on just a few here. We saw the fragment type. You can use an XPath selector to declare where that segment of relevant content is within the DOM. A very often used one is called Text Quote where the actual selected text is retained, as well as the text before and after it to kind of anchor it in the source, in the target source. And, you could even use CSS selectors if you felt like that was a good idea. But, by combining these together, it helps the annotation stay anchored as the Web page changes over time. Some are better. Some are more bullet -- I mean, you will not end up with something that’s bulletproof, but it is certainly more flexible.
And, sometimes even those kinds of selectors aren’t going to be enough, especially for Web pages like news sites because the homepage is just eternally changing. The model specification also gives you the ability to select based on state so that you could try to reconstitute the state that the target was in later when you’re reconstituting the annotation.
Okay, I could show you the details of all this in yet more JSON-LD, but I think we’ve seen enough JSON for the moment, so let’s carry on. So, whoosh - that’s the Web annotations in a nutshell, and now our virtual spaceship is zooming out a bit again.
Look again at higher level themes of how Web annotations in the Web as a whole relate to each other. Our first stop here is the struggle between freedom and control. The Web tends to promise democracy, power to the people, and open platform where everyone can have their say, at least an idealistic theory. It’s certainly an amplification platform. It allows the occasional, quiet, little dwarf star to go surprisingly supernova and garner a lot of attention.
Indeed, there are some examples of Web annotation used in ways like this to amplify voices that are positive or at least constructive. Take an organization called ClimateFeedback.org. The organization calls itself a global network of scientists fact-checking climate change news, and they do this by using Web annotations to, well, annotate news articles that reference climate change topics.
Here you see the opensource hypothesis browser tool open as a sidebar on the right overlaid on a climate-related article on the Conservative Tribune’s website. You can see here that scientists working together have been annotating within the article.
here, sort of zoomed in, is an example of an annotation made on some highlighted text within the article. In this particular annotation, the target is the article’s URI refined additionally by multiple selectors to identify the exact text that was selected by the annotation author. The body of the annotation, the scientist’s feedback, is here formatted as HTML. This is all pieces of an annotation represented.
This creates an annotation relating the scientist’s commentary to a segment within the target article. And, given that an annotation’s target can be any Web resource and an annotation itself is a Web resource, it so follows that one can create an annotation that targets another annotation. In translation, it means you can reply to an annotation, giving you the ability to apply annotations as, like, a threaded comment thread or within discussion forums, which sounds kind of great.
But, of course, we know that people can very much suck. A stroll through nearly any comment thread on the Web can show you this. The dehumanizing effect of physical separation and anonymity removes certain behaviors to people behaving pretty awful. Genuine awfulness works in many unmoderated spaces online, as we all know. This isn’t new, of course, or profound. The Web has long been fretting with tension of expressive freedom versus a cesspool of trolls. Nothing new under the sun here.
The Web annotation model doesn’t help us that much here. It defines a way that we can create an additional relationship to a creator, the person who authored the annotation. But, it’s an entirely optional thing. The details of identity, trust, authentication, and issues of access and moderation are left entirely up to implementors purposefully, again because the objectives of the working group working on the standards is to keep things as generic and high level as possible, not choosing any particular implementation technique because that would make an implementation more constrained and expensive. In short, it’s fairly complicated.
Plus, there’s the issue of control over the underlying content itself that is being annotated. Implementations of Web annotation software can be like a worldwide comment thread that the original content publishers can never mute or moderate. On the one hand, it’s like, yes, people should be able to say whatever they want about anything on the Web; it’s an open Web.
On the other hand, say you’re a content publisher and you’ve just realized there’s an entire layer of metadata about an article you wrote, and it’s awful, scathing, and possibly even untrue or inaccurate. What then? What are you supposed to do? Do we need to make it possible for content publishers to opt out of Web annotation by the use of some sort of crazy HTML attribute or using a script snippet or something, effectively disallowing Web annotations? But then, what happens if this is used by, say, a repressive regime to enforce censorship across a broad swath of sites? And, is it fair to put an onus on content creators to manage the situation?
Just because there is annotation content doesn’t mean it’s any good. Take my rant about T-Rex diets. I’m no scientist, and this body content has very little value to the Web community as a whole, especially anyone trying to find trusted or reliable content about science and dinosaurs. Annotation software can certainly build in moderation and muting of problem users and their crappy content, but then who gets to wield that banhammer? Can content creators moderate annotations made on their own sites? What if a user is unfairly banned? How can you even ascertain whether someone has authority over a site to be able to moderate something? And, who is in charge in this inherently “no one is in charge” open Web? This is very much an unsolved problem and one we’ve seen many times before on the Web.
All of this definition and standards making, cheerleading, and even implementations don’t mean a lot if ain’t no one using this thing. It feels like early days yet, even several years in. If annotating a resource is meant to be an interactive experience, then it can be pretty lonely for early adopters annotating resources that no one else is annotating yet. It’s rather a quite echo chamber in some spots.
So, we’ve been given this Web annotation standard, and what do we do with it? The standard is, by design, high level bordering on vague, which leads us to the danger of the tyranny of abstraction because, at the end of the day, standards in the Web built on them have to mean something to their users. They have to get useful stuff done.
The desire not to impose any domain specific structure has led to a rather generic standard. This flexible versus specific tension is one we see commonly on the Web. So, it becomes not a question of technology for technology’s sake, but a quest for satisfying true user needs. This heavy task falls to implementers, the job of translating annotation into something useful for real people to do real things with.
Merely saying, “Hey, here’s this abstract layer that you could, you know, put on a Web page and, you know, maybe chat with your friends about it or start saying stuff or troll or whatever,” that’s not enough. You’ll end up with a bunch of test comments, dead air, and people trying to figure out what the heck they’re actually doing, kind of shouting into the void. Put another way, getting people to adopt Web annotations is not solved at the, “Hey, the standard is done,” point. There’s a lot more to do to connect real humans to the power of what could be accomplished with the technology if indeed it is a useful technology to use.
Ah! The Web is never evolving fast enough. The standards process is time-consuming, though I would argue that there has been marked serious improvement and acceleration over the last few years helped by such initiatives as the Extensible Web Manifesto, increased overall interest in attention in the Web standards process, and a lot more people involved worldwide. But, we still face the classic tension of open versus proprietary, and we get itchy to get new features in front of users faster.
The same story, different day, in the short-term priority solutions that you build something fast and as featured as you want it to be. But, in the long-term, the Web does have a habit of ultimately, more or less, getting it right, getting it stable, and making it work for a broader set of people, but it sure takes longer. And, there’s no getting around that the standards process is somewhat byzantine. With the working groups and candidate recommendations and a heavy dose of process that can sometimes feel a lot like bureaucracy. The standard, in its abstraction, does give implementers the breathing room and the freedom to build things and adhering to it without being overly specific. And, the standard isn’t designed into a corner that would be invalid if the actual overall use for Web annotations pivoted a little bit.
Again, to come back to what is important in the specs, what’s keeping this technology true to the Web, one is interoperability, data portability, the notion that a properly implemented annotation system will give users the ability to export and move their annotations around between systems. Again, not aligning with any particular use case, but instead having the minimal elements to support various kinds of uses on top of it. Designing around the core tenants of the Web, like using URIs for identifiers, JSON-LD, RDF for metadata, and exchanging data using a RESTful protocol.
Still, how are people going to be using this? For a moment, to look at that, let’s talk about scientists for a few minutes. This is Maryann Martone. She’s a neuroscientist and professor at the University of California - San Diego. She edits or co-edits a whole number of scientific journals and is hugely interested in what she calls the interface between data and knowledge.
She believes that biochemists are failing at the main scourges that they’ve been trying to conquer for decades. Take Alzheimer’s or Parkinson’s disease. We’re simply not doing the best we can, she asserts.
This, like the Web, like reality, is part technology and part culture within the scientific community, according to Maryann. But, technology, like Web annotations, could help slow the loss of knowledge by allowing scientists and even computers to create connective tissue between data reports, articles, and human knowledge. Scientists are people trying to get certain things done, and they have a frame of reference for what they’re trying to do. And, if they’re using Web annotations, it’s not using annotations for annotation’s sake, but it’s because it allows them to get something useful done.
The scientists have user patterns that have helped shape some of the development of the hypothesis open source software, the ability to organize and share annotations within groups, to tag annotations. These features can live in a system built to the standard, as the standard does not preclude extensions to the model. It merely defines the core.
The promised interoperability of Web annotations is a boon to scientists and researchers who are working in different environments at different institutions. It could help the bleeding data loss caused by a lock-in and incompatible systems. The scientists in Maryann’s community have been successful at working and using Web annotations in various interesting ways so far, but there are certainly some interesting challenges, some missing pieces, and some workflows that just don’t quite fit for the scientists in that community.
For one thing, the URI, while being central to the Web’s definition of identification, isn’t the only game in town for scientists and scholarly publishers. In that space, in those fields, people tend to have an infinity for the digital object identifiers or DOIs. Often, DOIs are bound to URLs as identifiers, making them sort of interchangeable but, no, the DOI is actually fixed, while the URL might change. So, if the same article is hosted at two different URLs, the same DOI.
Not everyone thinks in terms of URIs all the time, and the scientists in Maryann’s community need more workflow built on top of annotation to make things sensible for them. They need to be able to move annotations around very flexibly between groupings, and they need to be able to move annotations between public and private types of visibility and share them selectively. They want it to be easier and faster to enact what they call a curatorial workflow.
Cool things are happening. A project called SciBot parses articles looking for a particular kind of identifier called an RRID and creates machine generated annotations against hypotheses API to connect a lot of different similar articles together along identified lines. In short, there’s a lot of experimenting going on, seeking new and better ways to organize, relate, and classify information to avoid the kinds of data loss that prevent bigger strides in bioscience.
“Some things are dead ends,” says Maryann, “but that’s what you get in a big, chaotic system. You rip it apart, and you try it again,” a chaotic system that we’re constantly slightly tearing down and rebuilding in different parts. Web annotations are a coherent part of that vast, imperfect universe.
As with the Web, we can totally say that Web annotations are noble, they’re practical, and they’re ours. We have ownership over our data. They can be brilliant and, yet, weirdly flawed at the same time, and the democracy that they inherently bring to the table also makes them somewhat uncontrollable.
So, we’re looking at a fight between freedom and control, the balance between freedom and control, as we have seen for so many years on the Web. We want to be ennobled to express ourselves, but there’s the ever-lurking threat of trolls. How do we figure out how to convert an abstract concept captured in some specs into useful things that users can do real things with - human beings can do real things with? And, how do we avoid falling into the tyranny of abstraction?
We itch to go faster and, yet, the Web can slow us down. But, in the end, Web annotations, like the immensity and the immense Web itself, need to help real humans do really useful things and solve real problems. And, I look forward to seeing what happens, as I am very, very curious.
Thank you.
[Applause]
