Web Annotation Working Group Charter [PROPOSED]

The mission of the Web Annotation Working Group, part of the Digital Publishing Activity, is to define a generic data model for Annotations, and define the basic infrastructural elements to make it deployable in browsers and reading systems through suitable user interfaces.

End date 1 October 2016
Confidentiality Proceedings are public
Initial Chairs Rob Sanderson, Stanford University
Frederick Hirsch, Nokia
Initial Team Contacts
(FTE %: 20)
Doug Schepers (10%) and Ivan Herman (10%)
Usual Meeting Schedule Teleconferences: Weekly
Face-to-face: One or two per year


Annotating, which is the act of creating associations between distinct pieces of information, is a widespread activity online in many guises but currently lacks a structured approach. Web citizens make comments about online resources using either tools built into the hosting web site, external web services, or the functionality of an annotation client. Readers of ebooks make use the tools provided by reading systems to add and share their thoughts or highlight portions of texts. Comments about photos on Flickr, videos on YouTube, audio tracks on SoundCloud, people’s posts on Facebook, or mentions of resources on Twitter could all be considered to be annotations associated with the resource being discussed.

The possibility of annotation is essential for many application areas. For example, it is standard practice for students to mark up their printed textbooks when familiarizing themselves with new materials; the ability to do the same with electronic materials (e.g., books, journal articles, or infographics) is crucial for the advancement of e-learning. Submissions of manuscripts for publication by trade publishers or scientific journals undergo review cycles involving authors and editors or peer reviewers; although the end result of this publishing process usually involves Web formats (HTML, XML, etc.), the lack of proper annotation facilities for the Web platform makes this process unnecessarily complex and time consuming. Communities developing specifications jointly, and published, eventually, on the Web, need to annotate the documents they produce to improve the efficiency of their communication.

There is a large number of closed and proprietary web-based “sticky note” and annotation systems offering annotation facilities on the Web or as part of ebook reading systems. A common complaint about these is that the user-created annotations cannot be shared, reused in another environment, archived, and so on, due to a proprietary nature of the environments where they were created. Security and privacy are also issues where annotation systems should meet user expectations.

Additionally, there are the related topics of comments and footnotes, which do not yet have standardized solutions, and which might benefit from some of the groundwork on annotations.

The goal of this Working Group is to provide an open approach for annotation, making it possible for browsers, reading systems, JavaScript libraries, and other tools, to develop an annotation ecosystem where users have access to their annotations from various environments, can share those annotations, can archive them, and use them how they wish.

In order to address these needs, this working group will work on deliverables chiefly focused in the following approaches:

  1. Abstract Data Model: An abstract data model for annotations
  2. Vocabulary: A precise vocabulary describing/defining the data model
  3. Serializations: one or more serialization formats of the abstract data model, such as JSON/JSON-LD or HTML
  4. HTTP API: An API specification to create, edit, access, search, manage, and otherwise manipulate annotations through HTTP
  5. Client-side API: A script interface and events to ease the creation of annotation systems in a browser, a reading system, or a JavaScript plugin

This work will take the form of several specifications as Recommendation Track documents, each of which will have considerations of security, privacy, accessibility, and internationalization implications for implementers, Web authors, and end users. Each specification must contain a section detailing any such known issues, and the Web Annotations WG will actively seek an open review for each Recommendation-track deliverable. Where possible, this working group will collaborate with other working groups to fulfill the goals of these deliverables.

The Abstract Data Model and the Vocabulary will start from the Open Annotation Data Model, developed by the W3C Open Annotation Community Group. The data model should provide a means to express provenance chains and license claims.

As many annotations will be viewed (and even stored) in HTML, one of the serializations of the data model may be in HTML (decorated with Microdata or RDFa), and another might be in a format suitable for embedding as metadata into media.

The Client-side API may consist of DOM events and a possible script interface.

The Robust Link Anchoring may define an algorithm, may be expressible as components of a URL or as a set of parameters on a hyperlink element, and may have CSS property considerations for styling the selection through a pseudo-element. The anchoring extension mechanism should address use cases such as maps and different data formats.

Robust Link Anchoring will be developed as a joint deliverable with the WebApps Working Group.

Each of the other work items may be loosely broken down into informal Task Forces, with their own mailing list to help focus discussions and address distinct communities.

Success Criteria

In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each feature defined in the specification, with comprehensive test suites and implementation reports for each specification.

Some deliverables assume native implementation in browsers, but because there are many different aspects of the overall ecosystem which are possible through incremental improvements, success of the work is not expected to depend on native implementations existing immediately.

Out of Scope

This working group will not produce Recommendation track documents on the user interface aspects of annotation management. Note that the Group may decide to publish user interface guidelines.


The titles of the documents may change. Also, some of the main deliverables may be split into separate documents, or merged into one document, based on the possible resolution of the Working Group.

In addition to normative specifications, the Web Annotations Working Group may publish use-case and requirements and best-practice documents.


Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD LC CR PR Rec
Annotation Abstract Data Model December 2014 December 2015 February 2016 May 2016 July 2016
Vocabulary for the Annotation Abstract Data Model. December 2014 December 2015 February 2016 May 2016 July 2016
Serializations of the Annotation Abstract Data Model. December 2014 December 2015 February 2016 May 2016 July 2016
HTTP API for Annotations February 2015 December 2015 February 2016 May 2016 July 2016
Client-Side API for Annotations February 2015 December 2015 February 2016 May 2016 July 2016
Robust Link Anchoring March 2015 December 2015 February 2016 May 2016 July 2016

Timeline View Summary

Note that if the new process document comes into effect, i.e., the LC and CR phases merge, then the February 2015 dates remain in effect for the new milestones.

Dependencies and Liaisons

The Web Annotation Working Group expects to follow these W3C Recommendations:

W3C Working and Interest Groups

WebApps Working Group  (new charter is under AC Review)
To jointly develop the Robust Link Anchoring mechanism in the Robust Link Anchoring Task Force. The liaisons should also ensure that the Client Side API is in line, in approach and style, with the various other API-s developed for Web Applications.
Digital Publishing Interest Group
To ensure that the use cases gathered by the Digital Publishing Interest Group are properly addressed by this group.
HTML Working Group
To discuss issues of markup, APIs, media, and events. For example, the Working Group may use custom elements for a targeted serialization of the Abstract Model in HTML.
CSS Working Group
To discuss issues of selection and styling.
SVG Working Group
To ensure annotability of SVG documents, including shapes as well as text, as well as making sure that Robust Link Anchoring approach can be extended for SVG.
Linked Data Platform Working Group
For coordination on LDP 1.1 as the basis of the HTTP API deliverable, if that is the chosen approach.
Web Applications Security Working Group
To discuss issues of security related to the HTTP and Client Side APIs, and cross-site access.
WAI Protocols and Formats Working Group
To ensure the accessibility of annotation services, both in reading and creating.
Social Web Working Group
For coordination on the Social API and the Federation Protocol (to be developed by the Social Web Working Group) and the HTTP API to be developed for annotation.
Internationalization Activity
To ensure that the deliverables are usable in all writing systems.
Privacy Interest Group (PING)
To ensure that the deliverables support the privacy choices of annotation authors and readers, e.g., when annotations are meant to remain private for the user, or they are meant to be shared to a restricted set of readers only.
Web Security Interest Group
To ensure that the deliverables meet good Web security practices.
Geo Data on the Web Working Group (charter under review)
To ensure that the Robust Link Anchoring approach can be extended for geographical information on the Web.

W3C Community and Business Groups

Open Annotation Community Group
For feedback and general community discussion.
CSS Selectors as Fragment Identifiers Community Group
To see if the result document of that community group can also be used as part of the Robust Anchoring discussions.

External Groups

IDPF EPUB Working Group
The Working Group has a project looking at ways to adapt the Open Annotation Community Group Draft for usage with EPUB 3. That work may reveal new requirements on the technical design of annotations that the Web Annotation Working group should take into account. Also, the results of the Web Annotation Working Group (e.g., the Client Side API) may be taken into account in the future evolution of EPUB, and may raise additional requirements.


To be successful, the Web Annotation Working Group is expected to have 10 or more active participants for its duration. To get the most out of this work, participants should expect to devote several hours a week; for budgeting purposes, we recommend at least half a day a week. For chairs, document editors, test leads, and other active roles, the commitment will be higher, approximately 1-2 days a week. The Working Group will also allocate the necessary resources for building test suites for each specification.


This group primarily conducts its work on the public mailing lists, and through annotations on the specifications.

Other topic-specific mailing lists may be added as needed. Administrative tasks may be conducted in Member-only communications.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Annotations Working Group home page

The role of dependencies and liaisons with various external groups is fundamental to the success of this Interest Group; the group will therefore set up active liaisons early in the process to ensure that the use cases and requirements are provided to other groups in a timely manner.

Decision Policy

As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

A formal vote should allow for remote asynchronous participation—using, for example, email and/or web-based survey techniques. Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 5 working days after the publication of the resolution in draft minutes sent to the group's mailing list.

Task Forces will make preliminary proposals to be decided by the consensus of the whole Working Group.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Web Annotation Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Ivan Herman, W3C, and Doug Schepers, W3C

$Date: 2014-07-15 16:22:49 $