I agree; anyone can say anything about any thing. This is what RDA says:
"A Uniform Resource Locator, or URL, is the address of a remote access resource.
Uniform Resource Locators include all resource identifiers intended to provide online access to a resource using a standard Internet browser.
Take information on Uniform Resource Locators from any source.
Record the Uniform Resource Locator for the online resource being described.
If there is more than one Uniform Resource Locator for the resource, record one or more according to the policy of the agency preparing the description.
Record a Uniform Resource Locator for a related resource as part of the description of the related manifestation."
"Resource" here means the RDA/FRBR entity Manifestation, and nothing else.
In practice, the URL recorded may resolve to (get) an online file constituting the real-world object that is the resource being described, or it
may resolve to a so-called jump-off page that links to various related versions/formats of the resource being described, or it may resolve to an interactive page such as a page-turner, and so on. All of these cases are covered by the instructions, but only
the first case allows a semantically coherent and machine-readable resolution of the data. Thus I think that the RDA URL data is non-resolvable (not un-resolvable) in the context of a coherent linked data application. It is a similar case to other Manifestation
identifiers, such as ISBN which cannot guarantee, in principle, that a single number/identifier refers to one and only one Manifestation.
I think it is important to make the distinction. If the RDA URL is treated as a URI, then what does the URI identify?
Suppose <resource1URI> <rdam:uniformResourceLocator.en> <URL1> .
If <resource1URI> and <URL1> are URIs for the same Manifestation, then <resource1URI> owl:sameAs <URL1> . This makes the URL property redundant.
If they are URIs for different Manifestations, then the RDA instructions are clear that the URL should not be recorded as a value of the URL property.
The RDA Steering Committee intends that the data produced using the RDA instructions and represented as linked data using the RDA element sets and
value vocabularies are coherent. There is nothing in this approach that is inconsistent with RDF or FRBR.
Applications are free to interpret the value of RDA URL as a URI that resolves to a web document; the RDA property does not declare a range. That
document might be the Manifestation/Item in focus, or a log-on form, or something else. Applications can also impose URI functionality on URLs declared as literals - but RDA data will not guarantee any consistency in the results.
This is the only reason I can come up with for an application needing to know the provenance, or anything else, of a URL in this context (was it
the location of some other document in the past? is it the location of some other document now?). Using RDF means we don't have to talk about URIs as identifiers; the provenance of a URI is all the triples that use it.
The RDA approach is evolving to conform to the new consolidated FRBR model, which introduces the entity Nomen. We expect the range of an evolved
sub-property of RDA URL (and many other elements such as titles of works and manifestations, names, access points, and other identifiers) to be declared as Nomen, allowing the provenance of any such identifying string to be recorded as linked data. The entity
has similar semantics and functionality as skosxl:Label.
Gordon – I suppose RDA is free to define URIs and URLs, and the distinction between them, as it sees fit, since there are already a number of different views.
But in my opinion, to consider a URL to be a non-resolvable identifier is a serious mistake.
In my view (just one of many), there is no substantive difference. Not that there is NO difference, but the difference is not worth the time to agonize over.
When I am discussing a link with someone unfamiliar in general with Web terminology, say, a link on a web page, I use “URL”. If I say “URI” they have no idea what I’m talking about. And the URL I’m discussing with that person is of course resolvable. On
the other hand, when discussing linked data, RDF, etc. I say “URI”; “URL” doesn’t seem to have much meaning in that context.
I recently wrote a brief primer on BIBFRAME RDF for LC catalogers. Upon introducing the URI concept, I said:
“At this point, people usually ask what is the difference between a URI and URL. For purposes of this discussion, there is no
substantive difference whose explanation would be of any value, so assume they are the same.”
Anyway, that’s how I see it.
And I’ll add that if one takes the view that they are substantially the same, it follows that it might be a good idea to standardize on one and drop the other.
And that’s what the WHATWG proposes
to do, standardize URL and
drop URI. Me, I prefer URI, but I won’t fight that battle.
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 hope this paper is of use – and please let me know (as Chair of the Working Group) if you disagree with anything.
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, 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
Karen, take this one step at a time. Suppose I have a triple:
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).
(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
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.
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.
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:
literal, in which case it’s enclosed in quotes (assuming turtle serialization); or
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
I maintain that it would be incorrect to instead say:
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:
In an RDF context, a resource can be anything that an RDF graph describes. A resource can be addressed by a Unified
Resource Identifier (URI)." 
"Any IRI or 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]."
There is similar language in the RDF 1.1 primer. 
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).
If bf:electronicLocator were to be redefined as an object property, then instead of this:
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.)
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: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).
[log in to unmask] http://kcoyle.net
[log in to unmask] http://kcoyle.net