Print

Print


On 11/12/15 12:05 PM, Denenberg, Ray wrote:
>
> 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.)
>

Ray, can you say more about this concept of a non-resource? AFAIK, many 
URIs do not dereference to  "RDF in response", but they are still 
considered resources in RDF. I'm looking at:

"90.Resource
In an RDF context, a resource can be anything that an RDF graph 
describes. A resource can be addressed by aUnified Resource Identifier 
(URI) 
<http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#uniform-resource-identifier>." 
[1]

"AnyIRI <http://www.w3.org/TR/rdf11-concepts/#dfn-iri>orliteral 
<http://www.w3.org/TR/rdf11-concepts/#dfn-literal>denotessomething in 
the world (the "universe of discourse"). These things are 
calledresources. Anything can be a resource, including physical things, 
documents, abstract concepts, numbers and strings; the term is 
synonymous with "entity" as it is used in the RDF Semantics 
specification [RDF11-MT 
<http://www.w3.org/TR/rdf11-concepts/#bib-RDF11-MT>]."[2]

There is similar language in the RDF 1.1 primer. [3]

This might be a terminology issue, but even accepting a different 
terminology, I'm not aware of any distinction where a response to the 
dereferencing of an IRI must be RDF (meaning? ntriples? JSON-LD?) rather 
than any RDF:resource (e.g. a jpeg file, an html file, an avi file).

kc
[1] http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#resource
[2] http://www.w3.org/TR/rdf11-concepts/#resources-and-statements
[3] http://www.w3.org/TR/rdf11-primer/

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

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600