On Nov 18, 2015, at 10:01 AM, Steven Folsom <[log in to unmask]> wrote:
I don’t think Karen is suggesting to derive meaning strictly from the name or labels of the property. She said the meaning comes from the semantics.
In my limited experience, as humans we come to understand the semantics through axioms and annotations in the ontology, and… honestly when the axioms and annotations are not not enough we have to go to the property or class names, documentation and examples to try to understand "the meaning". [As an aside, there are ontology matching tools that recognize this, and (along with other techniques) they analyze the lexicalization of the names as part of their algorithms to align classes and properties between ontologies.]
The criticism with <rdam:P30154> is that the semantics of the property (come to be understood through the lexical aliases and skos:description) are for a relationship AND what seems to be the expected range, e.g. Has remote access + range of URL. The skos:definition "Relates a manifestation to the address of a remote access resource.” and the fact that the range is actually undefined seems suggest something different from the lexical aliases. One could get remote access to a resource through a phone call, so is a telephone number a valid object of the <rdam:P30154> property?
I know Karen is advocating below for a more general rdax:location property, but maybe in this case we would want a more general rdax:access relationship that represents access to the resource. The object (in this scenario, a point of access) can be described through additional assertions about the point of access, whether it be a website, library, etc. The website and libraries can have a locations.
I’m not a RDA/FRBR expert, so I wondering what it means for a Manifestation to have a location at all. My sense is that Manifestations are still conceptual entities, and it would be Items that have locations.
<rdam:uniformResourceLocator.en> is a URI, as the angle-brackets indicate.
Actually, it's an RDA lexical alias that points to the canonical URI <rdam:P30154>. Lexical aliases are intended to give programmers some mnemonic support by reflecting the lexical label of the property in the "URI". Other lexical aliases for this URI are <rdam:uniformResourceLocator.de>, <rdam:localizadorUniformeDeRecurso.es>, and <rdam:adresseURL.fr> (awaiting activation). This human-readability comes at the cost of duplicating lexical aliases to preserve the mnemonic function if the property label changes, or perceptual semantic drift from the mismatch of alias and label.
This is a main reason why it is good practice to avoid embedding human-readable strings in a URI: human language changes and "meanings" drift, but URIs should be consistent persistent global identifiers. A more fundamental reason is that RDF works by completely separating the machine-readable identifier from the human-readable string. RDF expects all of the human-readable data in a triple to be stored as an object literal. Everything else is a URI.
The value of RDF data lies in the machine-programmable semantics of ontological statements about a property or class, and the human-readable definitions and scope notes stored as the objects of dataset triples. Using labels to store "meaning" involves too many issues; e.g.
<http://rdaregistry.info/Elements/e/P20003> reg:lexicalAlias <http://rdaregistry.info/Elements/e/otherDistinguishingCharacteristicOfTheExpression.en> .
The RDA Registry English label for the URL property P30154 is "has Uniform Resource Locator"@en; there is a variant RDA Toolkit label "Uniform Resource Locator"@en, and an internal Registry label“"uniformResourceLocator"@en. These labels are currently translated into French, German, and Spanish in the Registry and Toolkit.
So a machine would "see", e.g.:
<http://digital.nls.uk/78693432> <http://rdaregistry.info/Elements/m/P30154> "http://digital.nls.uk/rlstevenson/browse/pageturner.cfm?id=78693432" .
The URL string that is the object of this triple is clearly not intended to be permanent, and will return a 404 error when the publisher of this manifestation stops using a ColdFusion database server. The publisher recognizes this by providing a permanent URL that can be used as the canonical URI of the manifestation. Furthermore, the manifestation is currently embedded in a larger aggregate manifestation that can be accessed from this and every other "page" URL provided by the service. This URL moves the service to the first page of the manifestation described, but the last page is not recorded (in human or machine-readable form) so the manifestation segues into the next manifestation with URI <http://digital.nls.uk/78693516>.
I think it is better to leave this URL as a string in RDA data. I don't think RDA is overloading or masking the type of the value; isn’t that what Jeff is proposing?
The semantics of the value are made clear by the property:
a rdf:Property ;rdfs:domain <http://rdaregistry.info/Elements/c/C10007> ;skos:definition "Relates a manifestation to the address of a remote access resource."@en .The RDA instructions, given in my earlier post, do not burden the cataloguer with any of this. The RDA Steering Committee intends to develop the instructions to make explicit reference to recording URIs for RDF linked data, following recommendation 5 of the paper, but this will take account of the Nomen entity and the function of the URL as an identifier. None of the discussion so far compels me to suggest changing the RDA definition of the URL property.
As far as I know, none of I, my colleagues developing the RDA Toolkit and Registry, or the intended users of RDA, are in "the state of having a serious mental illness" or exhibiting "extremely foolish behaviour". Rather, it is our intention to avoid, not promote, "a state of wild or chaotic activity" :-)
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.
kcOn 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]> wrote:Ray, AllI 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.CheersGordonGordon – 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.Ray
--Karen Coylem: +1-510-435-8234skype: kcoylenet/+1-510-984-3600