Print

Print


Dear all,

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:

* Review
-- A review of an Instance or Work
* Summary
-- 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.

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

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

Thus:
_: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.

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305