It seems like I should be able to drop a physical "item" on my foot. 

Digital "items" are a bit more abstract, but somewhere at the end of the chain there must be *something* I can drop on my foot, even if it's a storage device like a hard disk or CD-ROM disk with a barcode on the jewel case.

And granted, some "items" may have been consumed in fires like this one:

Doesn't a FRBR notion of "item" depend on the possibility of someone in history saying "ouch" when that physical material drops on their foot?

It must be true that philosophy is an abyss. It seems like physicality is a convenient place for us to catch our breaths, though.

On Nov 12, 2015, at 9:19 AM, Bowers, Kate A. <[log in to unmask]> wrote:

Ah, hem. Special collections have a lot more they need to say about "items" than are dreamt of in your philosophy. Currently most of those things are kept in holdings records or in bib. records with $$3 or $$5 to specify the "institution" and/or "copy" to which it applies. 

Take, for example, this (author's own copy plus added material OCLC# 864841712) Harvard University Archives catalog record:  and this (where annotations are the more important content, online item to peruse: and finally my simplest case (annotated by former owner: Some special collections notes apply to all examples of the work while some apply to only the item in hand.

Does anyone know what BIBFRAME intends to do about these and similar cases?

Kate Bowers
Collections Services Archivist for Metadata, Systems, and Standards
Harvard University Archives
Cambridge, Massachusetts, USA
voice: (617) 384-7787
fax: (617) 495-8011
[log in to unmask]

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Hess, Kirk <[log in to unmask]>
Sent: Tuesday, November 10, 2015 3:24 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Properties of Item proposal

Item connects bibliographic descriptions to other library-centric data domains like circulation, which I think was what made this challenging to model. The key things in this proposal to me were items have identifiers, a barcode/electronic locator and have relationships to other resources which arenít bound by a fixed number of levels.


I agree properties like subLocation are incomplete and would be more fully described in a working system or a future version of the vocabulary. In that particular case maybe we should use the usageAndAccess pattern, with subLocation expecting a Location class?


I also imagine an implementer would extend bf:Item and add those three properties you mentioned as local properties. A few months ago I reviewed the Kuali OLE item table and there were about 20 circulation-type fields, so itís going to take a lot more properties to address those two tasks.



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: Tuesday, November 10, 2015 1:39 PM
To: [log in to unmask]
Subject: [BIBFRAME] Properties of Item proposal


Items in BIBFRAME may serve different purposes, which is not addressed in the Items proposal.  A relatively narrow purpose is to support the user task obtain, while a more complex one is to support a working circulation system.  The properties elaborated in the proposal are not sufficient even for the user task obtain.  Here are comments on them.


bf:electronicLocator:  should the expected value be a URI?  It seems odd to express URLs as literals in linked data.



bf:heldBy and bf:subLocation:  the MARC holdings format and many library systems recognize three levels of location information: organization, library and sublocation within a library.  BIBFRAME should support the same number of levels:  for example, it should add a property such as bf:location, which is intermediate between bf:heldBy and bf:subLocation. 


bf:heldBy University of Washington Libraries

bf:location:  Art Library

bf:subLocation:  Reference stacks


bf:heldBy University of Washington Libraries

bf:location:  Engineering Library

bf:subLocation:  Reference stacks


Without bf:location, reference or general stacks locations in different buildings appear to be the same.



bf:itemOf:   is a reciprocal property needed?  For example, bf:hasItem, a property of bf:Instance with an expected value of bf:Item.



Two properties are lacking from the proposal:  bf:itemStatus and bf:circulationCharacteristic


bf:itemStatus:  it is crucial to inform users of the status of an item, e.g. available, checked out, missing, withdrawn, at the bindery, etc.


bf:circulationCharacteristic:  another important aspect of materials is the general policy that governs them, e.g. circulating or library use only.  It is tempting to try to include this characteristic in bf:itemStatus, but they are independent aspects.  LUO materials may be missing, at the bindery or even checked out (e.g. faculty loans of reference materials).