Print

Print



On 11/16/15 10:37 AM, Denenberg, Ray wrote:
>
> Hi Karen – Yes there certainly is a terminology issue, particularly 
> because the expression “RDF resource” does not have a formal 
> definition, anywhere (that I have ever been able to find).
>

Actually, Ray, the quotes I gave you in my email are indeed the formal 
definition from the W3C specifications. There is probably an even more 
formal definition somewhere using virtually unreadable notation, but I 
think that what the human-readable documents say is quite clear -- which 
is that a resource is "anything that an RDF graph describes" and that it 
can be either an IRI or a literal. I agree with you that folks often 
refer to IRIs as resources as opposed to literals, but that's a 
misnomer. Another way of saying this is "string vs. thing" but there's 
probably some ambiguity in that as well. But most importantly, as I said 
below, nowhere have I encountered any statements that there is any 
distinction made that what one obtains upon dereferencing must be "RDF". 
In fact, I don't know what that actually means.

Your http://hdl.loc.gov/loc.pnp/cph.3g11323, which very clearly follows 
the rules for an IRI (and IRIs do not need to be dereferenceable) is an 
IRI. What it does or does not dereference to does not change that. You 
can treat an IRI as a literal string (I don't think there's anything in 
RDF to prevent that) -- and therefore indicate that you don't intend it 
to be actionable as an IRI. However, again, your distinction of "imply 
that you can retrieve RDF by dereferencing" is not familiar to me.

kc


> However, whenever I encounter the expression it seems to be used in 
> the sense that I’m using it.   Which is this:
>
> In any RDF triple the object is a literal or an RDF resource.  A 
> literal is of course a resource; and I am making a distinction between 
> “resource” and “RDF resource”.
>
> So, the object of a triple is either:
>
> 1.a literal, in which case it’s enclosed in quotes (assuming turtle 
> serialization); or
>
> 2.not enclosed in quotes, in which case it is an RDF resource URI 
> (either enclosed by curly braces or using namespace prefix notation), 
> or a blank node id.
>
> For case 2, the URI can be dereferenced resulting in an RDF 
> description or if it is a blank node it points to an RDF description.
>
>
> Do you agree (so far)?  If you think I’m using the expression “RDF 
> resource” incorrectly then what is your definition?  If you think “RDF 
> resource” and “resource” mean the same thing, I disagree, but then, I 
> could be wrong, since “RDF resource” has no formal definition.  But 
> I’m using it in the sense that I see it used.
>
> Anyway, having said all that, getting back to the example at hand
>
>  bf:electronicLocator  [
>
>         a    bf:ElectronicLocator ;
>
>    rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323” 
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> ] ;
>
> I maintain that it would be incorrect to instead say:
>
> bf:electronicLocator  <http://hdl.loc.gov/loc.pnp/cph.3g11323” 
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> >
>
> because that would imply that you can retrieve RDF by dereferencing 
> http://hdl.loc.gov/loc.pnp/cph.3g11323 , which (as far as I know) you 
> can’t.
>
> Ray
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle
> *Sent:* Sunday, November 15, 2015 8:30 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> 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>*denotes*something 
> in the world (the "universe of discourse"). These things are 
> called*resources*. 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> 
> <http://bibframe.example.org/item/item5>
>
>           a bf:Item ;
>
> bf:electronicLocator      “http://hdl.loc.gov/loc.pnp/cph.3g11323” 
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> ;
>
> ……
>
> It might look like this:
>
> <http://bibframe.example.org/item/item5> 
> <http://bibframe.example.org/item/item5>
>
>           a bf:Item ;
>
> bf:electronicLocator  [
>
> a    bf:ElectronicLocator ;
>
>    rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323” 
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> ] ;
>
> ……
>
> 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] <mailto:[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] <mailto:[log in to unmask]>  http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600

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