Print

Print



On 11/18/15 7:01 AM, Steven Folsom wrote:
> 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.

+1 to "access" as the semantics of a property.

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

I agree, and started to write "rdai:location" with "rdai" for item. But 
it does get tricky and the whole M vs. I isn't as neat as it could be, 
(see PeteJ link below) which is why the division of data into disjoint 
classes of WEMI often doesn't work for me. The use of URLs in 856 was/is 
often ambiguous, as is the use of URLs by publishers of resources.

But this then gets us into the whole "locator vs. identifier" question. 
When I first heard that Linked Data would use http URIs it struck me as 
being a mistake, since it confounds location and identification. So we 
get the whole httprange-14 bit (readers: see below for definition*) to 
try to disambiguate. But in fact we've always had ambiguity between 
identifier and locator on the web, and what we have in our records today 
is an instance of that ambiguity.

As per the previous posts, you often don't know what the URL actually 
resolves to, and what it resolves to at the time of cataloging may not 
be what it resolves to in the future. This, of course, is a perfectly 
reasonable machine task -- one we perform frequently with link checkers 
-- run through a bunch of URLs and see what comes back. That "see" is 
limited to what the machine can see, but it is up to date and "real." 
The idea of trying to "fix" this a priori and manually during the 
cataloging process does not strike me as viable. Anyone can re-use a URL 
in their possession for anything. All everyone else can do is go and see 
what is there at this moment, today.

kc
*httpRange-14 is a very complex (in my mind) way to disambiguate 
http-based locators from identifiers. It's not something that humans 
should need to be aware of, it's part of the negotiation between an http 
request (e.g. coming from a browser or a web-based program) and the site 
receiving the request. It makes sense to some site developers, it seems, 
but I've given up trying to understand much more than I've just said 
here. See: https://en.wikipedia.org/wiki/HTTPRange-14, which describes 
it as a "long-running logical conundrum." And it even references FRBR 
and a lengthy discussion of FRBR and the http conundrum: 
http://efoundations.typepad.com/efoundations/2009/02/httprange14-cool-uris-frbr.html 
by Pete Johnson.

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600