Ray, All


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

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


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.






From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: 17 November 2015 20:20
To: [log in to unmask]
Subject: Re: [BIBFRAME] Properties of Item proposal


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.





From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Gordon Dunsire
Sent: Tuesday, November 17, 2015 9:16 AM
To: [log in to unmask] <mailto:[log in to unmask]> 
Subject: Re: [BIBFRAME] Properties of Item proposal




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 (page 4 and
following). The RSC accepted recommendation 1 and is taking appropriate


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.






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] <mailto:[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. 




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.




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






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, 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:

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   "
<> " ] ;


I maintain that it would be incorrect to instead say:


bf:electronicLocator  <
<> " >


because that would imply that you can retrieve RDF by dereferencing , which (as far as I know) you can't.





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 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 a
ifier> Unified Resource Identifier (URI)." [1]

"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]."[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). 


If bf:electronicLocator were to be redefined as an object property, then
instead of this:



          a                                        bf:Item ;

          bf:electronicLocator      "
<"> "  ;



It might look like this:



          a                                        bf:Item ;

          bf:electronicLocator  [

                                                   a    bf:ElectronicLocator

<> " ] ;



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





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: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]>
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600


Karen Coyle
[log in to unmask] <mailto:[log in to unmask]>
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600