I was talking to Ross a bit in channel about this, but one consideration is encouraging consistency.

If everyone uses http://purl.org/dc/elements/1.1/[whatever] to identify that, that's fine. If some people were using that, and other people were using http://purl.org/NET/dc..., and other people were using http://dc.org/..., and other people were inventing new things all the time, it would be problematic.

That's unlikely to happen to DC. In part because the DC organization, which is responsible for the DC elements, has officially endorsed and propagated those particular identifiers.

So long as everyone is using the same http identifiers, they are indeed inter-changeable with info style identifiers, with the added bonus that they potentially have some kind of de-referencing built in, and that they don't make things more complicated with non-http URI schemes. (Those two are the arguments for using http, right?).

With something that was in fact created for the web, by a particular organization, that published those http uris.... this is quite likely to occur.

With legacy identifiers that were not created by the web (like sudoc), that potentially have a distributed mechanism of control (like ISBN, and in a different way DOI), and especially where the controlling organization has not in fact endorsed a _particular_ http template for URIs... it's somewhat more likely for there to be confusion, and lack of consistency. Which would cause problems.

Karen seems to be saying that becuase _lots_ of people don't understand the difference between http URL as a locater for a particular protoclol, and http URI as an identifier independent of de-referencing, this confusion could become a problem.

From my point of view, http URIs _used with consistency and apprpropriately_ and info URIs are more or less interchangeable. But they both have pros and cons in terms of convenience (the convenience of being able to de-reference a URI as a locater to mroe information), and in terms of likelyhood of encouraging consistency. One of the benefits of info is that it comes with an inherent built-in registry to encourage consistency.


Ross Singer wrote:
I would counter that Dublin Core has been pretty successful with:




More so than MODS and SRU combined, I would say.  What does that say
to you (other than LC's bad SEO strategy)?


On Wed, Apr 1, 2009 at 12:55 PM, Ray Denenberg, Library of Congress
<r...@loc.gov> wrote:
A concrete example.

The MODS schema, version 3.3, has an info identifier, for SRU purposes:


So in an SRU request you can say"


Meaning you want records returned in the mods version 3.3 schema.  And
that's really the purpose of the schema identifier. Both the client and
server know the schema by this identifier  - or the server doesn't know it
at all and the request fails - but nobody wants to resolve the identifier.

Now in contrast, the schema is at

And it's also at:

And also:



So there you have five http "identifiers" for the schema.

Which is the better identifier for this purpose? The single info identifer,
or a choice http identifers, one for  every possible location where the
schema may reside (which is more than these five).    If the answer is that
it's better to use one of the http identifiers, how do you know that the one
you pick is the one that the server recognizes it by?  Or should the server
maintain a list of all possible locations?


----- Original Message ----- From: "Ross Singer" <rossfsin...@gmail.com>
Sent: Wednesday, April 01, 2009 12:26 PM
Subject: Re: [CODE4LIB] resolution and identification (was Re: [CODE4LIB]
registering info: uris?)

On Wed, Apr 1, 2009 at 12:22 PM, Karen Coyle <li...@kcoyle.net> wrote:
But shouldn't we be able to know the difference between an identifier and
locator? Isn't that the problem here? That you don't know which it is if
starts with http://.
But you do if it starts with http://dx.doi.org

I still don't see the difference.  The same logic that would be
required to parse and understand the info: uri scheme could be used to
apply towards an http uri scheme.


Reply via email to