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