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