Contributions > Service Genres > Annotate 1.1 Login
  Minimize

 
      Minimize
Name
 
  • Name: Annotate
Rationale
 

This Service Genre has been developed from a wide range of projects and work across the partners. Systems are often required to allow users to make comments, notes or other annotations to existing data items within a collection, without alterting the base item itself. This Service Genre has been developed to show the functionality and behaviours required of Services that seek to fulfill this requirement.

Classification
 
Domain(s) [ ] Learning & Teaching [ ] Research
[ ] Libraries
[ ] Administration
[ ] IT Services
[X] Common
Maturity [ ] Immature [X] Mature
Development Scale [ ] Isolated [X] Ubiquitous
Status [X] Approved [ ] Placeholder
[ ] Unapproved
[ ] Superseded
[ ] Withdrawn
Confidence Level [ ] High [X] Medium [ ] Low
Version
 
  • v1.1
Version History
 
Version Date Author Description Organisation / Project
v1.1 2007-02-28 Phil Nicholls
Initial Draft - based on previous work
JISC 
Description
 

This Service Genre describes the assignment of annotations from an open ended set to an object. An example of this might be to add a footnote to a document, or to add a comment to a blog entry.

The original object MAY be modified by the Annotation Service. Annotations MAY be applied to a proxy of the original object. Annotations MAY be included as metadata. The Service Genre does not dictate how annotations are to be attached to the original object. There is no limit to the number of annotations that can be made to an object.

Annotations are made by specific actors and the identity of the Annotator SHOULD be made known. Anonymous annotation is OPTIONAL.

As defined the Annotate Service Genre is not access controlled. Any client may attempt to contact an Annotate service end point. There are no authentication controls. The service end point is responsible for determining which individual objects can be Annotated and which clients can make annotations to existing content.

Functionality
 

The Annotate Service Genre supports functions that enable the creation, update and deletion of annotations:

Apply annotations: Add a new annotation to an existing resource or content. The annotation would typically be text, and would represent a footnote, endnote or inline comment. Services would modify either the original content, a proxy, or add an attachment as defined by the Service Expression.

Remove Annotation: Remove an existing annotation from an existing resource or content.

Edit Annotation: Edit an existing annotation. Services modify the target annotation, however it was applied to the content. Annotations must exist in order to be modified.

No other functionality is defined. The functionality that is defined MAY be extended.

Usage Scenarios
 

Annotation Services are useful in distributed collaborative environments. Authors can share comments on work, leading to improvements in quality.

Applicability
 

Annotation SHOULD NOT be used as an alternative to issuing new versions of the original source object.

Care should be taken with Annotations when controlled editing of documents is used.

Annotate SHOULD be used when an unordered, unbounded value is to be assigned to an object.

Annotations MAY be applied to collections of objects as well individual objects.

Annotate SHOULD NOT be used if an ordered, bounded value is to be assigned to an object. Rating SHOULD be used instead.

Annotate SHOULD NOT be used if an unordered, bounded value is to be assigned to an object. Classify SHOULD be used instead.

Requests & Behaviours
 

Requests SHOULD be implemented to enable all functionality.

Create Annotation SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The author of the annotation.
    • The target object to be annotated.
    • Data which is the annotation.

Remove Annotation SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The author of the annotation.
    • The target annotation to be altered.
    • The new data which is to be the annotation.

Edit Annotation SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The target annotation to be deleted.

Responses SHOULD:

  • Indicate any error conditions (such as the Annotation not being accepted).
Use & Interactions
 

Individual Service Expressions SHOULD provide models showing how clients interact with service interfaces.

Structure
 

 

Applicable Standards
 

None

Design Decisions and Tradeoffs
 

Authorisation SHOULD be considered when specialising this Service Genre. Specifically, whether owners of the original object are authorised to delete and edit Annotations. Additionally, Service Expressions should consider whether Annotations can be modified by other Annotators.

The management of which objects can be annotated SHOULD be considered by the Service Expression or SUM which incorporates Annotation.

Implementation Guidance and Dependencies
 

 

Known Uses
 

Annotea

Related Service Usage Models (SUMs)
 
Related CORE SUMs
 

None


Intellectual Property Rights: This document is governed by the e-Framework Intellectual Property Rights Statement [http://www.e-framework.org/Default.aspx?tabid=738]. © Copyright, JISC, DEST & e-Framework Partners 2007. This document may be used under the Creative Commons Attribution-ShareAlike 2.5 Australia License [http://creativecommons.org/licenses/by-sa/2.5/au/].


The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].

The Service Genre description uses e-Framework Service Genre description elements as of 2006-12-09, updated to include draft e-Framework service classifications. Other terms, e.g., client, provider, and resource, are used as defined in the e-Framework.

 
Related SUMs   Minimize
 
    Minimize
Unless otherwise noted material from the e-Framework website can be downloaded for your own use under a Creative Commons Attribution-ShareAlike 2.5 Australia License
CreativeCommons-by-sa.png
 
Thursday, August 28, 2008
Copyright e-Framework Partners 2006 - 2008

Terms and Conditions

Privacy Statement