# Comments on 26 Aug BIBFRAME annotation model draft 
Of the four use cases (section 1.2), which correspond with the four
top-level annotation classes (section 6.2), it seems that the one really
special to the library/book world is bf:Holding, and maybe bf:CoverArt
is somewhat. The long thread discussing issues around holdings perhaps
bears this out. Notions of description and review are very general and I
remain unconvinced that these especially should not be done using Open
Annotation (see, e.g parallel motivations oa:describing and
oa:commenting ). However, I'll put that aside for now.
One of the key tensions in bibframe is between the idea of local data
and externally provided or 'extrinsic' data as described in section 2.2.
Section 2.2 emphasizes the 'BR' which in that section I think has to be
read as "bibframe record" (the local data) rather than "bibframe
resource" in the sense of the web architecture . The distinction
between intrinsic/extrinsic as presented is about authority and that
sits awkwardly in the web world. To me the key motivation for an
annotation model (rather than use of a direct predicate relationship
such as "x is_a_review_of y") is that one can then make statements about
the act of annotation (who did it, when, why, etc.).
I think the predicates "bf:payloadSource" and "bf:payloadSourceLink" do
not play well in RDF. In the case of multiple annotation bodies, which
do they refer to? In even the existing set of classes there are two
bodies for cover art (bf:coverArt and bf:coverArtThumb). This ambiguity
is removed if instead the body (or bodies) is the subject of predicates
indicating the source (e.g. "body bf:source authority"). When I first
read this I assumed bf:payloadSource and bf:payloadSourceLink were
designed to allow easy addition of source information for annotation
bodies represented as literals rather than resources. However, I see
that the "Content in RDF" approach is used (like Open Annotation )
and thus do not see why source and sourceLink are not properties of the
## Editorial notes
### date format
The examples show dates in the ISO8601 form without hyphens (e.g.
'20131010') for bf:dateOfAssertion while claiming the range is xs:date.
The definition of xs:date admits only the variations of ISO8601 with
hyphens (i.e. '2013-10-10') and so I think either the examples or range
must be changed. (I note that this issue was discussed in detail in 
in relation to premis)
### example domains
The examples use domains 'xyz.org', 'xyz.com', 'local.org' for dummy
URIs. Some of these resolve and it would be better to stick with
official example domains (such as 'example.org' and 'example.com'  to
avoid possible confusion with real domain names.
### section 5.1 Cover Art
The image has a property "annotates" whereas the set of triples has more
specific sub-property "bf:coverArtFor". I assume the image should have
On 8/26/13 2:43 PM, Denenberg, Ray wrote:
> *BIBFRAME Annotation Model -
> BIBFRAME Community Draft, 26 August 2013 (*second draft) **
> As with the previous draft (April 30) this is a work in progress,
> comments and discussion encouraged.
> Thanks to the BIBFRAME community, including the Early Experimenters, for
> the many comments and suggestions, which have resulted in what we think
> is a significantly improved document.
> Ray Denenberg
> Library of Congress