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.
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:
a bf:Item ;
bf:electronicLocator “http://hdl.loc.gov/loc.pnp/cph.3g11323” ;
It might look like this:
a bf:Item ;
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.)