No, not identical URIs.
Let's say I've put a copy of the schema permanently at each of the following
locations.
http://www.loc.gov/standards/mods/v3/mods-3-3.xsd
http://www.acme.com//mods-3-3.xsd
http://www.takoma.org/standards/mods-3-3.xsd
Three locations, three URIs.
But the issue of redirect or even resolution is irrelevant in the use case
I'm citing. I'm talking about the use of an identifier within a protocol,
for the sole purpose of identifying an object that the recipient of the URI
already has - or if it doesn't have it it isn't going to retrieve it, it
will just fail the request. The purpose of the identifier is to enable the
server to determine whether it has the schema that the client is looking
for. (And by the way that should answer Ed's question about a use case.)
So the server has some table of schemas, in that table is the row:
["mods schema] [ <URI identifying the mods schema>]
It recieves the SRU request:
http://z3950.loc.gov:7090/voyager?
version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=<URI
identifying the mods schema>
If the "URI identifying the MODS schema" in the request matches the URI in
the table, then the server know what schema the client wants, and it
proceeds. If there are multiple identifiers then it has to have a row in
its table for each.
Does that make sense?
--Ray
----- Original Message -----
From: "Ross Singer" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 01, 2009 2:07 PM
Subject: Re: [CODE4LIB] resolution and identification (was Re: [CODE4LIB]
registering info: uris?)
Ray, you are absolutely right. These would be bad identifiers. But
let's say they're all identical (which I think is what you're saying,
right?), then this just strengthens the case for indirection through a
service like purl.org. Then it doesn't *matter* that all of these are
different locations, there is one URI that represent the concept of
what is being kept at these locations. At the end of the redirect can
be some sort of 300 response that lets the client pick which endpoint
is right for them -or arbitrarily chooses one for them.
-Ross.
On Wed, Apr 1, 2009 at 1:59 PM, Ray Denenberg, Library of Congress
<[email protected]> wrote:
We do just fine minting our URIs at LC, Andy. But we do appreciate your
concern.
The analysis of our MODS URIs misses the point, I'm afraid. Let's forget
the set I cited (bad example) and assume that the schema is replicated at
several locations (geographically dispersed) all of which are planned to
house the specific version permanently. The suggestion to designate one
as
cannonical is a good suggestion but it isn't always possible (for various
reasons, possibly political). So I maintain that in this scenario you
have
several *location* none of which serves well as an identifier. I'm not
arguing (here) that info is better than http (for this scenario) just
that
these are not good identifiers.
--Ray
----- Original Message ----- From: "Houghton,Andrew" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 01, 2009 1:21 PM
Subject: Re: [CODE4LIB] resolution and identification (was Re: [CODE4LIB]
registering info: uris?)
From: Code for Libraries [mailto:[email protected]] On Behalf Of
Karen Coyle
Sent: Wednesday, April 01, 2009 1:06 PM
To: [email protected]
Subject: Re: [CODE4LIB] resolution and identification (was Re:
[CODE4LIB] registering info: uris?)
The general convention is that "http://"; is a web address, a location.
I
realize that it's also a form of URI, but that's a minority use of
http.
This leads to a great deal of confusion. I understand the desire to use
domain names as a way to create unique, managed identifiers, but the
http part is what is causing us problems.
http:// is an HTTP URI, defined by RFC 3986, loosely I will agree that
it is a web addresss. However, it is not a location. URIs according
to RFC 3986 are just tokens to identify resources. These tokens, e.g.,
URIs are presented to protocol mechanisms as part of the dereferencing
process to locate and retrieve a representation of the resource.
People see http: and assume that it means the HTTP protocol so it must
be a locator. Whoever initially registered the HTTP URI scheme could
have used "web" as the token instead and we would all be doing:
<web://example.org/>. This is the confusion. People don't understand
what RFC 3986 is saying. It makes no claim that any URI registered
scheme has persistence or can be dereferenced. An HTTP URI is just a
token to identify some resource, nothing more.
Andy.
