This DRAFT charter is under development; it has currently no formal standing, and has not been reviewed by the w3c Advisory Committee, the Director, or W3M. It may be improved, finalized, or abandoned, depending on feedback.
The goal of this text is to provide a framework for a public discussion
on the creation of an annotation working group at w3c. We also
anticipate getting community perspectives on the scope of this proposed
charter AT a Workshop on Annotation that w3c plans to organize on April
2nd, San Francisco, co-located with the I Annotate conference. The
current plan is to revise and finalize the charter soon after that
Once the charter is finalized, it will be reviewed by the director and
W3M and then sent to w3c members for formal approval.
The mission of the 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 April 2017|
|Confidentiality||Proceedings are public|
|Initial Chairs||CHAIR INFO|
|Initial Team Contacts
(FTE %: 30)
|Ivan Herman (15%) and Doug Schepers (15%)|
|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.
In order to address these needs, this working group will work on deliverables chiefly focused in the following approaches:
This work will take the form of several specifications as Recommendation Track documents.
The Abstract Data Model and the Vocabulary will be informed by the Open Annotation Data Model, developed by the W3C Open Annotation Community Group.
As many annotations will be viewed (and even stored) in HTML, one of the serialization 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 Robust Link Anchoring may define an algorithm that can be expressed 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 Client-side API may consist of DOM events and a possible script interface.
These work items will be loosely broken down into two informal Task Forces, the Data Task Force and the Client Task Force, each with their own mailing list to help focus discussions and address distinct communities. It is expected that many participants will be active in both areas. Over the course of the Working Group, this organizational structure may be changed to meet the needs of the group.
The Data TF will focus on the Abstract Data Model, Vocabulary, and Serializations, and RESTful API.
The Client TF will focus on the Robust Link Anchoring, Client-side API, and some aspects of the Serializations and the RESTful API.
[Replace this text] Describe Success Criteria.
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.
[Replace this text] Identify which deliverables are expected to become Recommendations and which are expected to become Group Notes. Identify documents that are expected to become W3C Recommendations but that are (per the transition procedure) not covered by the W3C Patent Policy. Please indicate whether any specification is likely to be a delta specification intended to become a normative Recommendation. Note: Does this group have CPP documents that were CR or PR when the group first transitioned to the W3C Patent Policy (meaning they would still be CPP) but that the group now plans to publish as a Working Draft? If so, please contact the W3C Communications Team for instructions.
[Replace this text] Describe any other deliverables such as test suites, tools, or reviews of other groups' deliverables.
[Replace this text] Specification transition estimates and other milestones
|Note: The group will document significant changes from this initial schedule on the group home page.|
|FooML||Month YYYY||Month YYYY||Month YYYY||Month YYYY||Month YYYY|
|BarML||Month YYYY||Month YYYY||Month YYYY||Month YYYY||Month YYYY|
[Replace this text] Put here a timeline view of all deliverables.
Furthermore, Annotation Working Group expects to follow these W3C Recommendations:
To be successful, the 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 mailing list
archives. Discussion on data topics will take place on
and discussion on client-side and browser topics will take place on
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 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.
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.
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.
This charter for the 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.
Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved.
$Date: 2014-02-03 17:15:44 $