Hi Joseph � thanks for the comments and questions.� I want to address two points, while we are still discussing the other suggestions.


bf:electronicLocator is, at present, conceived to be a datatype property; its expected value is a literal. �We could change that to an object property if that�s what people want, however, the URI would still be a literal, because it is not an RDF resource. ��In the example, the electronic locator is and this is not an RDF resource. (By RDF resource, we mean, you can dereference the URI and get RDF in response. You can�t for this URI.)� If bf:electronicLocator were to be redefined as an object property, then instead of this:



����������a��������������������������������������� bf:Item ;

��������� bf:electronicLocator����� ��� ;



It might look like this:



����������a��������������������������������������� bf:Item ;

��������� bf:electronicLocator �[

�������������������������������������������������� a ���bf:ElectronicLocator ;

������������������������������������������������ ���rdf:value ���� ] ;

����� ��


Where here we now have defined class bf:ElectronicLocator, but the URI is still a literal.



Second, should bf:itemOf (property of item) have a reciprocal property, bf:hasItem (property of Instance).

I don�t know; opinions are welcomed on this question.� We did not include it in the draft for this reason: an item knows (or should know) what Instance it is an Item of.� An Instance in general does not know the existence of all items that claim to be an item of that Instance. So if there were to be a property bf:hasItem, it could be used within an Instance to point to all items that that Instance knows about with the disclaimer that it doesn�t claim to point to all its items. If, as such, this would be useful then we can add the property.� (The same dilemma applies to instanceOf and hasInstance. And granted, these are both included in BIBFRAME 1.0.)





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