Print

Print


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