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
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
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
> <[log in to unmask]> 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" <[log in to unmask]>
>> To: <[log in to unmask]>
>> 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 <[log in to unmask]> 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.