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