...
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.