Annotation Service Description and Assumptions

Description

The Annotation entity manages a schema used to add extended, structured annotation to an object (a la property bag, but allowing for some structured properties a la RDFS or something). This will look a lot like other structured information we bind to an object, such as insurance information, conservation, etc. This may end up being a utility service to manage the schema.

There will be some general common metadata around authorship and review, and we need to consider what information is in an Annotation entity and which must be modeled in the association of an Annotation to some object (e.g., a CollectionObject).

We will need to broadly model the association of metadata with an object. We need to consider the association of an Annotation entity, but also must model associate of a Reference like an URL, or a bibliographic reference, a Resource (like an image, a recording, or a document), etc. How do we capture the common aspect of the association so it is easy to find all annotations (associations) for an object? We *could* just enumerate all the association services, but this is a bit messy to maintain. It would be nicer to have a more general notion that support variants (subclasses). This can be done with an association-type, but then we need to figure out how that gets messy.

Issue: Where do we draw the line between what is stored logically in obj, and not?

Note distinction between the info in an annotation and the act of the annotation association. Subtle, but this is the data model showing through. The social act is significant, as a document may have one author/creator, and the association to an object may have another creator.

Note that may annotate at any level in the hierarchy of objects (i.e., we can annotation an individual object, a group of objects, or an entire collection). This in turn means that we must be able to query for (or otherwise model) inherited annotation values from ancestor object structures. This raises the question of annotating all the objects in, e.g., an exhibit. It is one thing to annotate the exhibit, and another to annotate all the objects in the exhibit. But if the object hierarchy does not include the exhibit grouping (it generally will not, as the exhibit groups are an orthogonal way of grouping objects), then we have to annotate each object individually. But if an object is tentatively included in the exhibit and then withdrawn, how to we track this and remove the annotation applied to the exhibit objects? This can get messy.

Annotation extent

Annotation may be associated to an extent of a resource, for image hotspot/regions, temporal annotations, etc. Certain classes of objects (and representations) more naturally support extent-based annotation than others. E.g., where the object is an audio recording, temporal extent is a natural way to annotate, and images can clearly leverage spatial extent. For other classes of object this may be difficult or less-than-useful. E.g., should we really support annotation of a spatial extent of a statue, when we cannot reasonably translate this to an image of the statue? Suppose we can establish scale of the image - should we support this then? Extent of an annotation defaults to the entire extent, so the simple case is to ignore extents. Note that temporal annotation requires considerable UI support to do properly. Note that temporal annotation does not necessarily imply that the system can deliver temporal sub-sets (sub-clips) or playlists, both of which are server and codec dependent functionality.

Assumptions

• Try to be explicit and exhaustive, but not pedantic.
  • ~pschmitz@berkeley.edu: If there is an active discussion or comment, you may want to call it out as a sub-bullet. This example also uses a color macro to call it out, and provides a link to a given user to indicate that this is a particular contributor's position.

Subtopic

• More assumptions around peripheral subject
  • Ex. An example of the case
• Yet another assumption
  • Details of the assumption
    • Nitty-gritty detail 1
    • Nitty-gritty detail 2

Key Concepts

• Especially things that become common sense, and so usually missed by new reviewers

Dependencies

• Note other services that are consumed or that are closely related to this one

Background Documentation

• If we have notes from community design meetings, link to them here.
• If we have relevant sections in Spectrum or another such document, link to them here (or cite section numbers, etc.)