Print

Print


I agree with Jeff. The semantics of the value should be made clear by 
the property, and not by overloading or masking the type of the value.

I think the problem is in the property 
"<rdam:uniformResourceLocator.en>" It should be something more like 
"rdax:location" if that's what the value means. URL is a kind of thing, 
not a relationship between entities. "ex:hasURL" (if you want to make it 
into a verb) is essentially about the the lowest semantics I can 
imagine. We don't create properties like "ex:string", we create 
properties that say what the string is about, such as "dct:title" or 
"skos:label". URL should be the value, not the predicate.

And if the URL goes to a splash page, well, it goes to a splash page. In 
line with the conversation we've had with Ray, your metadata can't 
control what's on the other end, and catalogers are not omniscient nor 
can they see into the future. What if the URL after a while returns a 
404? How can cataloging rules have any control over that?

I don't think that linked data is going to be any more perfect than 
unlinked data has been. And I don't think that we should burden humans 
with decisions about things that are arbitrarily outside of their 
control. That way lies madness.

kc

On 11/17/15 5:54 PM, Jeff Young wrote:
> I'd say put them all in angle brackets. The ones that "get it" will 
> rise to the top. The others are easily sniffed for what they are.
>
> On Nov 17, 2015, at 5:35 PM, Gordon Dunsire <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>> 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 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.
>>
>> Cheers
>>
>> Gordon
>>
>> *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] <mailto:[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 
>> <https://whatwg.org/> proposes to do, standardize URL 
>> <https://url.spec.whatwg.org/> and drop URI. Me, I prefer URI, but I 
>> won’t fight that battle.
>>
>> Ray
>>
>> *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
>>
>> 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 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] <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.
>>
>> 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%E2%80%9D> ;
>>
>> ……
>>
>> 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