On 11/18/15 7:01 AM, Steven Folsom
[log in to unmask]"
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]"
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
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.
*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:
by Pete Johnson.
[log in to unmask] http://kcoyle.net