On Jan 13, 2015 11:19 AM, "Robert Sanderson" <[log in to unmask]> wrote:

> I'm less concerned about exact definitions and more about the last case of HeldItem as a subClass of Annotation.  Regardless of the exact definition, I suggest that it is impossible for the same resource to be both a real world physical object and a digital annotation at the same time.  

> [...] much less important than the fundamental inventory recording capabilities of the ontology.

Given the assumptions made by the rest of BIBFRAME...

If you were any more bang on, you would be surrounded by the black and white Fictitious Spirits of a thousand librarian stereotypes going 'shhhhhhhh' [1]

In order to perform an inventory, it is important to be able to count all the things.  Because it is an annotation, HeldItem, brought in to counter criticisms raised over the original Holding-as-Annotation, fails to solve the original problem, which is that there is nothing in the Ontology of BIBFRAME that corresponds to the thing that you can drop on your foot, hardback,paperback, or machine-rack.

Two bibframe Annotations made by two different annotators are two different annotations. They might refer to the same entity, and have the same contents, but they are just as distinct as two different annotators giving a work a 4-star rating.  

There may be something in the annotation that allows you to infer that there is some thing, outside the bibframe universe, that they both refer to, but those things lurk outside the BIBFRAME universe.

The most plausible definition of BIBFRAME Annotations is  as carriers for information not directly contained within a MARC 21 bibliographic record. 

Table of contents information is an exception which proves the rule; there is a note field (505) that can hold TOCs small enough to fit in a Z39.2 formatted record.  However, the table of contents in a 505 may be stored by reference (via the $u);  indirect tables of conference may also be linked to via an 856 field.  Similarly, summary information might be provided through a 520, but might be indirectly linked to via an 856.  

See http://lccn.loc.gov/93003471 for an example of both uses of 856. 


[1] Plus one cybrarian going 'ssh'.