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