This description is a textual description of the required properties for annotations. It is based on the work done while defining the first RDF example and a refined protocol for annotation.
An annotation has a type that has a meaning to a group of people using it. Annotation can be many things: a generic comment, an evaluation, a typographic correction, insertion or deletion of text, hypothesis developed based on a document paragraph, a bookmark, a question etc. Definition of an annotation depends on the group communicating by using it and the definition is going to evolve over time as the group develops its process.
An annotation probably needs to be an RDF class so that new subclasses can be defined whenever the workgroup realizes they need them. An annotation type with a description of the values is probably needed in addition to having the class/subclass structure.
The annotation also refers to another document or sometimes several documents. For instance, a document can have an annotation with a general comment referring to a certain paragraph in a document or it may refer to that paragraph in several versions of the document until it is corrected. There might also be a case where an annotation has several internal targets in a document where it points to. For instance, an annotation correcting similar typos can refer to all the places where the typos appear instead of creating the same annotation many times.
The annotation needs to have a Pointer that consists of a document URI (relatedDoc) and an optional internal target or range. If there is no target the annotation refers to the whole document e.g. recommendations of good documents. The annotation can have several Pointers in which the document URI or the targets or both can vary. Before XPointer is fully implemented we intend to use fragment IDs for targets.
An annotation also has an author (sometimes maybe even several authors), a creation time, and a last modification time.
For these we can use Dublin Core.
The body of the annotation contains the actual comment. Most often it is a short text but it can also be a structured document, maybe even video. This (body) document may exist already or it is created when the annotation is created so it may have a URI that can be given by the user or it needs to be created.
The annotation needs a body element. The most difficult problem is to define the protocol so that the server will create this second URI without two POST operations. It is not clear if the schema can help to solve this problem, probably not.
The annotation may have some related comments that are stored as mail messages in discussions lists or as ETA issues etc. It should be possible to add URI links with flexible types (e.g. discussions, issues, related spec etc.) and descriptions to these kinds of comments too. What we want to present like this develops over time with the group's working style. At the beginning these may be presented as markup in the text of the body. Later they may want to describe these links as properties so that it is easier to see the relationships of the resources that the annotation integrates.
This last part is is still evolving. At least we need to have properties of type otherInfo. Maybe this is another class and can be later evolved by developing subclasses to it?
See notes from 1999-12-10 annotation meeting.
Marja & Ralph
$Date: 2000/05/18 13:37:08 $