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).