Print

Print



On 11/17/15 6:16 AM, Gordon Dunsire wrote:
>
> All
>
> The JSC Technical Working Group discussed the issue of URL vs URI in a 
> paper discussed by the RDA Steering Committee a few days ago; see 
> http://www.rda-jsc.org/sites/all/files/6JSC-TechnicalWG-6.pdf(page 4 
> and following). The RSC accepted recommendation 1 and is taking 
> appropriate action.
>
> The basic conclusion is that a URI is a thing (RDF resource), and a 
> URL is a string (non-resolvable identifier). This is reflected, I 
> think, in the basic syntax of RDF: a piece of data in quotes is a 
> string (human-readable) and all other data in a triple are things 
> (machine-readable URIs). Using angle-bracket and quote delimiters, the 
> two basic triple syntaxes are:
>
> <subjectURI> <propertyURI> <objectURI> .
>
> <subjectURI> <propertyURI> “object string” .
>

I do find this to be odd, but perhaps it needs further explanation. A 
URL is a URI, by definition. And URLs are indeed resolvable. I guess I'd 
say that a non-resolvable identifier is a string (ISBN, LCCN); but if 
you have a URL you can't know that it is non-resolvable until you try to 
resolve it. As Ralph said, you can't decide a priori what the response 
will be. You can decide, for yourself, that you do not wish to resolve 
certain well-formed URIs and put them in strings, but calling those URLs 
does not seem correct.

kc

> I hope this paper is of use – and please let me know (as Chair of the 
> Working Group) if you disagree with anything.
>
> Cheers
>
> Gordon
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Denenberg, Ray
> *Sent:* 16 November 2015 22:19
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> Well of course.  You can never guarantee good behavior of an 
> independent system.  I’m only saying that these are the rules we are 
> supposed to be playing by.  If I encounter an object of a triple which 
> looks like an RDF resource URI, I dereference it (requesting RDF), and 
> you refuse the request, I’d consider that a failure.
>
> Ray
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *LeVan,Ralph
> *Sent:* Monday, November 16, 2015 4:58 PM
> *To:* [log in to unmask] <mailto:[log in to unmask]>
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> Ray, my VIAF server does provide RDF when asked via content 
> negotiation.  Today it does.  So, today triples that have a VIAF URI 
> in them are legal, but tomorrow when I break content negotiation they 
> suddenly become illegal?  It’s impossible for the coiner of the triple 
> to guarantee some third-party server behavior.  It’s up to the 
> consumer of the triple to identify those URIs that are pointers to RDF 
> and do whatever seems appropriate.
>
> Ralph
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Denenberg, Ray
> *Sent:* Monday, November 16, 2015 4:14 PM
> *To:* [log in to unmask] <mailto:[log in to unmask]>
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> Karen,  take this one step at a time.  Suppose I have a triple:
>
> <some subject>   bf:someProperty   <http://someURI>
>
> Where again I am using turtle notation and I am explicitly enclosing 
> http://someURI  in angle braces.   I claim that http://someURI 
> (enclosed in angle braces) must be dereferenceable as RDF (meaning 
> that there is an RDF representation of that resource, http://someURI, 
> which may be one of many representations, and I can get that RDF 
> representation by doing a get on it requesting RDF via content 
> negotiation).
>
> Do you not agree?
>
> (And you’re saying that “RDF resource” is defined in the documents you 
> cited, but that expression doesn’t even occur in any of those 
> documents.  Nowhere. So I’m confused.)
>
> Ray
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle
> *Sent:* Monday, November 16, 2015 3:44 PM
> *To:* [log in to unmask] <mailto:[log in to unmask]>
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> 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] <mailto:[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] <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