On 11/18/15 7:01 AM, Steven Folsom wrote:
[log in to unmask]" type="cite">
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.

[log in to unmask]" type="cite">

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