This document describes the set of use cases generated for Annotation and Social Reading within the W3C Digital Publishing Interest Group, in coordination with the Open Annotation Community Group.
This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered here, tell us! The initial version of this document will focus on books, and at this time will not include requirements specific to magazines or newspapers. The scope will depend heavily on the willingness of people to contribute to this document. Please contact the Digital Publishing Interest Group if you would like to help.
Annotation is a pervasive activity when reading or otherwise engaging with publications. In the physical world, highlighting and sticky notes are common paradigms for marking up and associating one's own content with the work being read, and many digital solutions exist in the same space. These digital solutions are, however, not interoperable between systems, even when there is only one user with multiple devices.
This document lays out the use cases for annotations on digital publications, as envisioned by the W3C Digital Publishing Interest Group, the W3C Open Annotation Community Group and the International Digital Publishing Forum. The use cases are provided as a means to drive forwards the conversation about standards in this arena.
The use cases are divided into five sections: annotations that target only the entire publication, annotations that target a particular part of a publication, more complex annotations, the publication of annotations and finally use cases that are directly related to accessibility.
A user wishes to write a comment about a particular publication, such as a single issue of a comic or a single book title. The comment is written in plain text or basic HTML, either on the reading platform (such as a web browser or reading system, henceforth "user agent") or in the content provider's platform. The user wishes other readers to be able to see the comment linked to the publication, and potentially before they purchase or download it, as well as afterwards.
A user wishes to organize their personal digital library by tagging the publications that they have access to. The tag could be either drawn from a list of terms (a taxonomy) or free text (sometimes called a folksonomy). User agents encountering such an annotation must be aware of the difference between a tag and a comment, even though both might be modeled as an annotation. Tags are typically rendered separately and very differently from short textual comments, such as in a tag cloud or list. The user then wishes to view their library partitioned via the tags. The user may wish to share their tags with other users to help the recipient categorize their own library, or find publications of mutual interest.
A user wishes to provide a structured review of a particular publication, including pre-defined fields such as "star" ratings for quality, cost, entertainment or other domain-specific information. The review could also include a full text description, such as the comment in the first use case. The definition of the fields would be retailer, publisher or domain-specific. In the scholarly domain, this could be expected to provide a distributed and standardized peer-review system, rather than the current use of vendor-specific interfaces. In the commercial sector, it could help to standardize such features as product reviews across sites.
A user wishes to link an existing web resource, such as a blog post or uploaded video, to the particular publication that it is about. The comment could be any online resource, in any format. The user wishes other readers to be able to see the resource linked to the publication, and potentially before they purchase or download it as well as afterwards.
A user wishes to contribute their experience in the form of a comment, and wishes to remain known as the author of that content and annotation that links it to the publication. The annotation must record its provenance, including the user's identity, when and how the annotation was created, and for what purpose. This provenance is important for appropriate display of the annotation, filtering or ordering of annotations, maintaining and assigning credit for annotations, determining allowed usage of the annotation, and many other similar requirements.
Desirable metadata features:
Note that many of these features are desirable for the body and target resources as well.
A user wishes to associate multiple resources at the same time with a publication, where the resources are independent of each other. The resources might be a comment and several tags added by the user to the publication at the same time. Alternatively, tags might be extracted from the comment's text by an automatic process and added to the annotation about the publication after the user agent confirms their relevance.
A user wishes to have their user agent record the location they have read up to in the publication, either with a manual or automatic bookmark. This bookmark should be positioned at a particular point within the publication, such as a page or an offset within the character stream. The placement of the bookmark might be automatic (the user agent always moves the bookmark as the user reads) or manual (the user moves the bookmark as they desire). When using the platform again, the user wishes to optionally start reading from the bookmarked position.
The user also wishes to share this position with others to show how far through the publication they have progressed. This might be publically shared for bragging rights, shared semi-publically such as a reading group or class, or shared privately between platforms that the user has access to in order to maintain the position between devices.
A user wishes to highlight a span of text in a publication for emphasis. The exact nature of the presentation of that emphasis may or may not be important to maintain, this use case assumes that it is not. The emphasis might be to mark a passage of particular importance, a typo or other mistake, something to cite in another document, to bring to the attention of other readers, or to mark two such selections for comparison. The user may wish to share the highlight, and certainly wishes it to be accessible on multiple platforms to which she has access. In this use case there is no requirement to provide a comment or body of the annotation, simply to record a highlighted span of text.
A user wishes to make a comment about a particular span of text. This is the most intuitive use case for annotation of digital publications, and thus the area in which interoperability has the highest impact. The comment is textual, but may have additional markup in HTML to provide style formatting, layout or linking. The Annotation should be sharable, as per the other use cases.
A user wishes to make a comment about a particular resource that is embedded as part of the publication, such as an image or video. In the general case, the user would expect to somehow select the embedded resource and then launch the interface for adding comments in the same way as commenting on text. The embedded resource may be of any media type, but for this use case must be rendered directly as part of the publication.
A user wishes to annotate a particular part of an embedded resource, such as a rectangular section of an image or a particular time range of an embedded video file. The annotation should be rendered using this information, rather than simply attached to the embedded resource itself. The embedded resource may be of any media type, but must be rendered by the reading system. Thus video, image, audio and similar are in scope for this use case, but not stylesheets or scripts which are not rendered directly. Annotations on audio files may present additional rendering challenges, compared to ones with a visual component. The user then wishes to share the annotation with others.
The parts of resources to be annotated include:
A user wishes to write a comment about a resource embedded within the publication, and to associate it with alternate, accessible representations of that resource, such as the alt text/long desc provided. The comment may be only about part of the alternate representation, and thus segments of the alternate representation must be able to be selected. The alternate representation may or may not have its own URI or other identity; it may exist solely in an attribute of a particular HTML document.
A user wishes to annotate two or more parts of a publication, embedded resources, or part of an embedded resource, in order to compare or contrast the targets. This may be to point out inconsistencies in the content or rendering, to make a note about two similar or related passages, or to link part of an embedded resource to where it is referenced in the text.
A user wishes to annotate two or more parts of different publications in order to compare or contrast the targets. This may be to make a note about two similar or related passages such as plagiarism, or to link part of an embedded resource to where it is referenced elsewhere. For example, the user may wish to link appearances of the same character in multiple books, popular references to prior works, or examples of passages that contradict each other in scholarly literature.
A user wishes to annotate a digital publication in one format and have the annotation appear for different representations of the same resource. For example, an annotation created on an EPUB should also be rendered on the equivalent PDF or HTML page. The annotation can be either on the publication level, or anchored to a particular part of the text. Annotations on embedded resources (such as images) that are embedded without identity in alternate representations are not considered in scope, for example annotating a part of an image in an HTML page which is then embedded within the PDF representation of the page.
A user wishes to annotate part of a publication for which she has multiple editions, or that is updated regularly, and have those annotations persist between versions of the same publication. If the publisher provides a new version of a publication, known to happen silently at times for various reasons, then the annotations about the publication should be available on this new version rather than equally silently disappearing. As with any annotation that should be presented with more than just the resource it was created for, cross versioning allows for a wider audience and thus is a potential target for spammers.
This use case is particularly challenging to solve in environments in which identifiers for the work, rather than the particular version, do not exist.
A user wishes to associate a particular style with an annotation, either for the comment or the delineation of the target of the annotation. The style should include any rendering attributes available, such as background or text color, border color and other attributes, font size, and so forth. When colors or styles associated with annotations are meaningful to an individual, to a particular group, or just generally, a text label should be able to be associated with the annotation drawn from a list of terms (taxonomy) or free text, in order to assist with accessbility.
A user wishes for their annotations to be presented at a particular location on the page, such that the layout of the annotations doesn't interfere with the reading of the publication. For example, annotations could be styled as a particular height and width, and then put into the margins of the page or over top of other white space. Annotations could be visually ordered such that reading them in the presented order gave a better experience than reading them in the order of the targets within the publication. Thirdly, the layout could be used for organization of thoughts concerning the publication by moving all of the related annotations together spatially. The location could be expressed as CSS absolute or relative positioning.
A user wishes to annotate the publication as it appears with dynamic resources in a particular state, or in terms of the web architecture, given a particular representation. Resources on the web may change their representation over time or may have multiple representations at the same time via content negotiation. The URI of the resource alone is thus not sufficient to determine the representation that was delivered to the annotator, and additional information such as the time of the request and the HTTP headers sent must be recorded.
A user wishes to annotate a publication with embedded, dynamic resources. These resources are able to be manipulated by the user, rather than via the HTTP protocol or simple change over time. Some number of manipulations must be performed in order for the target of the annotation to be visible or understandable, regardless of the accuracy of the description of the target segment. The consuming user agent should then be able to reproduce these manipulations in order to allow a third party to see the resource as annotated.
This use case is particularly challenging to solve in the generic case rather than with media specific solutions.
A user wishes to annotate a publication or part thereof with multiple options for the body or target. The options are thus dependent on each other, and only one of the options should be displayed to the user. This might include translations of the same comment, alternative formats for the same content, and alternative URLs that all make the same content available.
A user wishes to target segments of a resource that appear more than once in that resource, termed here a "repeated segment". The user does not necessarily know the exact number of times the repeated segment appears in the resource; the interpretation of the annotation is understood to be independent of the number of instances of the repeated segment.
A user annotates a publication with a correction to the text. The publisher then acts upon this annotation to correct the mistake, or in the scholarly field potentially to retract the publication from the scientific record. After the correction has been made, the annotation no longer applies to the publication and hence should not be displayed. It may be important not to delete the annotation, such that the user gets credit in some system for reporting the correction. The system that maintains the annotation may not be connected to the system that publishes the publication, and hence might not be able to be updated.
This use case is particularly challenging to solve in the generic case rather than within specific systems that understand the motivation of the annotation and when it has been resolved.
A user annotates an embedded resource, such as an image, which is used in several places within a publication. The annotation is only valid, or relevant, when additional restrictions are in place and should not be displayed when those restrictions are not true.
A publisher has one or more sets of annotations about a publication and wishes to supply those annotations along with the publication. Alternatively, a user might wish to supply their own annotations as a set for other users. These annotations could be comments by the author (in the same vein as DVD extras commentary), from famous readers, or simply pointers to related works. In an education setting, this functionality could be used to provide additional commentaries on a text book or other publication that are intended to assist the student in understanding the material. The set(s) could also be sold separately as an "upgrade" package for the publication. The order of the annotations may be important, for example to read the publication in chronological rather than narrative order, or by following the order of a class lectures rather than the order of the chapters in the text book. The metadata about the collection of annotations is also important, such as who packaged them together and for what purpose.
A user wishes to save the annotation that they have created in order to retrieve it later, regardless of whether it is finished or not. The Annotation should be given a unique and resolvable identifier. The user may wish to save the annotation in their own system, rather than the system which provides the resource being annotated. The user may equally wish to save the annotation in multiple systems. The annotation should persist in local storage if the user is offline, and be persisted globally once the connection is re-established. In the interim, a locally unique identifier should be assigned to the annotation. Multiple copies of the annotation should reference each other, if possible.
Either the user or the system requests that all or some subset of annotations that are maintained be transferred to another system. If the user requests it, then it this enables an export functionality such that the user's annotations can be exported to another platform or device. If the system requests it, then this enables a synchronization functionality where the user's annotations will be maintained in multiple locations for ease of use and preservation, or aggregation for analysis. Both such cases should use the same mechanism.
A user wishes to keep their annotations or personal notes private, or only share with a small group of people such as a reading group, academic research group or only with a set of friends in a social network. Even if the user wishes to keep their annotations private, the ability to transfer the annotations between devices is desirable, so that they be used regardless of the particular reading platform.
The user may also wish to keep only some aspect of the annotation private, for example the comment should be protected, while the annotation graph can be shared openly, or vice versa. Regular web based authentication and authorization structures should be used to enable this functionality in an online environment to ensure interoperability.
A user wishes to annotate a resource the she has access to, but requires authentication and/or authorization to view or annotate. The annotation should not circumvent or allow the circumvention of this DRM, for example by reproducing the content of the target publication.
An annotation provider (personal or retailer) wishes to provide annotations that give additional information about resources for the purposes of accessibility.
Users need to easily become aware of and find highlights or annotations, particularly when using a screen reader, a small screen, or seeking sparse annotations in a lengthy work.
A user wishes to provide internationalization information for a document that they don't conrol, such as a translation for a particularly complex phrase, or whether automated translation systems should explicitly not translate a given phrase.
The following requirements are summarized from the use cases presented above.