Joe –

 

You said: “If bf:electronicLocator must expect a literal, then the current proposal is better than your suggested alternative:  less complex.”

 

let’s step back and look at an example where the literal is just a string, not a URI.

 

Take bf:sublocation:

 

      bf:subLocation       “Prints and Photographs Division Washington, D.C. 20540 USA” ;

 

So it is a datatype property (i.e. expected value is literal).  But an argument can be made that it could be an object property (expected value is RDF resource).

Suppose Prints and Photographs Division were an RDF resource, meaning, there is an RDF description of it, which you get by dereferencing  http://bibframe.example.org/location/LCprintsAndPhotographs.

 

Then you would want to be able to say

      bf:subLocation       <http://bibframe.example.org/location/LCprintsAndPhotographs >

 

But you can’t, if bf:sublocation is defined to be a datatype property, and you still want to be able to supply the string “Prints and Photographs Division Washington, D.C. 20540 USA” in case you don’t know that URI.

 

So the general solution to this problem, that we have adopted for BIBFRAME 2.0, for the case where you may want to supply an RDF resource URI, or you may want to supply a string, is to define the property as an object property, define a corresponding class, in this case, bf:Sublocation, and you can say either this:

 

           bf:subLocation    a bf:Sublocation ;

            rdfs:label                    “Prints and Photographs Division Washington, D.C. 20540 USA” ;

or this:

 

      bf:subLocation       <http://bibframe.example.org/location/LCprintsAndPhotographs >

 

Or even this:

 

      bf:subLocation       <http://bibframe.example.org/location/LCprintsAndPhotographs >  .

 

<http://bibframe.example.org/location/LCprintsAndPhotographs >

                       a                         bf:Sublocation ;

            rdfs:label                    “Prints and Photographs Division Washington, D.C. 20540 USA” .

So yes, this approach is more complex, but might be more linked-data friendly.

 

Ray

 

 

 

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: Friday, November 13, 2015 11:43 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Properties of Item proposal

 

If bf:electronicLocator must expect a literal, then the current proposal is better than your suggested alternative:  less complex.

 

Concerning a reciprocal link, I think it will be useful to have in the model.  You are right that in general an Instance will not know about all Items related to it, but in specific local implementations it will be more efficient to link to known Items.  The model should at least provide that possibility.

 

Joe

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: Thursday, November 12, 2015 12:06 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Properties of Item proposal

 

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 http://hdl.loc.gov/loc.pnp/cph.3g11323 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:

 

<http://bibframe.example.org/item/item5>      

          a                                        bf:Item ;

          bf:electronicLocator      “http://hdl.loc.gov/loc.pnp/cph.3g11323”  ;

……

 

It might look like this:

 

<http://bibframe.example.org/item/item5>      

          a                                        bf:Item ;

          bf:electronicLocator  [

                                                   a    bf:ElectronicLocator ;

                                                    rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323” ] ;

      ……

 

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

 

Ray

 

 

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