In the W3C Web Annotation Working Group, Ray raised the use cases that BibFrame has for annotations. While there has been some interesting discussion in that forum, I think it's more appropriate to discuss the finer details here, and hence this message to try and transition the deeper modeling questions to the right place.
bf:Annotation has 5 direct subClasses:
-- A review of an Instance or Work
-- A description of an Instance or Work
Reviews and Descriptions are canonical use cases for annotation, and the model is very clear -- the body of the annotation is the review/summary text, the annotation is the linking construction and the target is the Work or Instance.
The key point of these is that different reviews and different descriptions can all be equally valid, as they are subjective and depend on the annotator's point of view.
-- The association of cover artwork with the Instance
Linking resources together also seems like a reasonable usage of annotation, though the requirement for an annotation to do this, rather than simply including it in the resource's description is less clear. It is less obvious that there's any subjectivity, but I can see that different images might be used by different institutions for the same Instance.
-- The table of contents of an Instance or Work
Less obvious again, as there's likely only a single correct answer for the table of contents, and multiple institutions would be unlikely to want to have different versions of the ToC. It seems like a very specific summary of a single part of the resource.
In both CoverArt and TableOfContents the identity of the resources is still clear: the body is the artwork or transcribed table of contents, the annotation is the association, and the target is the instance or work.
And finally ...
* HeldMaterial (with HeldItem as a further subClass)
My position is that the current BibFrame model does not make appropriate use of Annotations in this case, and I think it would be significantly easier to understand and implement if Items were real resources or the annotation conveyed something slightly different.
In particular, the Annotation resource (HeldItem) has a lendingPolicy, an electronicLocator, accessConditions, retentionPolicy and so forth. These are not the features of a link or association, they're the features of a physical object that the library holds. A single URI cannot identify both a physical object and a conceptual association at the same time.
My test for conflation is always: when was the resource created? The annotation was not created at the same time as the physical object, therefore there must be two separate resources.
Option 1. The annotation conveys only a single notion, that the agent creating the annotation owns a copy of the target resource.
Thus the same semantic pattern as other annotations follow:
The annotation represents the notion that the agent creating the annotation owns a copy of the target resource, which is the Instance.
The body might not be present at all if there's no identifier for the physical object, or could be the identifier for the physical object if there is one.
This is still somewhat strange -- it doesn't fit with the other uses of Annotation as above, nor is it the same model as the relationships between Instance and Work, or Work and Work.
Option 2. Don't use annotations for this, and make HeldMaterial a subClass of bf:Resource, with a real relationship (isCopyOf or similar) with a range of bf:Instance.
_:x a bf:Work . // Lord of the Rings
_:y a bf:Instance ; // Harper Collins printing 2010
bf:instanceOf _:x .
_:z a bf:HeldItem ; // Rob's copy of Harper Collins printing 2010
bf:copyOf _:y .
With all the current properties that HeldItem and HeldMaterial have. This is the option that I strongly prefer.
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305