[OAI-implementers] Clarifications added to
Thomas G. Habing
thabing at uiuc.edu
Tue Mar 14 14:06:25 EST 2006
Hi Simeon and all,
I am a little concerned about these changes to the oai-identifier
recommendation. While for historical reasons we probably need to allow
"A single namespace-identifier may be used for identifiers in multiple
repositories operated by the same organization." For new repositories,
I would rather discourage this.
My experience with the OAI Registry at UIUC has shown that it is
difficult if not impossible to develop useful registry-based services,
similar to Jeff Youngs ERRoL service, but also other services, unless
the namespace-identifiers assigned to repositories are unique to just
What we have done when confronted with this problem at UIUC is to
register domain name aliases for each of our OAI providers, even if
those OAI providers all reside on the same server. Thus we have:
Each of these is a registered domain name, but each is just an alias for
some other domain.
I also suspect that many people might have the misconception that the
domain name used for the namespace-identifier must or should match the
domain name of the server which is hosting the data provider (the domain
name part of the baseURL). This is also not true, and can cause
problems for people who might think that if they move their data
provider to a new baseURL that they need to change all the oai
identifiers to match.
Although not strictly necessary, this is another advantage of using a
domain name alias as the namespace-identifier. If you wanted, you could
redirect the alias to a new domain if you ever needed to move the
So I guess my recommendation would be to temper your revisions somewhat,
maybe something like this:
Primarily for backward compatibility with previous versions of this
specification, a single namespace-identifier may be used for identifiers
in multiple repositories operated by the same organization. The same
oai-identifier description block would then be used in the responses to
Identify requests for each repository. However, organizations are
strongly encouraged to assign a unique namespace-identifier to each of
their repositories, even if those repositories are served from the same
host. Registering domain name aliases for each of these repositories is
a possible solution that guarantees uniqueness even for repositories
hosted by the same organization from the same server. Uniqueness of the
namespace-identifier is thus guaranteed through domain name registration
and not through registration with the OAI validation service, as it was
Simeon Warner wrote:
> Prompted by comments from Eloy Lafuente (copied below) I have added 2
> small clarifications to the oai-identifier v2.0 specification. The new
> version is online at:
> the new version with changes highlighted in red is at:
> and the old version is at:
> The change from the v1.1 oai-identifier specification to v2.0 meant that
> namespace-identifier part of the identifiers (e.g. arXiv.org in
> oai:arXiv.org:hep-th/9901001) is no longer tied to the registration of a
> single repository. Uniqueness is attained from tying the
> namespace-identifier to DNS registration. I have also changed the
> validator service in accord with this understanding.
> Thanks to Carl Lagoze for sanity checks.
>>> De: Simeon Warner <simeon at cs.cornell.edu>
>>> Fecha: Tue, 20 Dec 2005 18:07:01 -0500 (EST)
>>> Para: Eloy Lafuente <eloy.lafuente at si.unirioja.es>
>>> CC: <openarchives at openarchives.org>, "joaquin.leon at bib.unirioja.es"
>>> <joaquin.leon at bib.unirioja.es>
>>> Asunto: Re: One question about identifiers...
>>> Hi Eloy,
>>> I have noticed this problem with my own use of oai:arXiv.org:XXXX
>>> identifiers for arXiv.org and multiple OAI servers. The problem is that
>>> the specification was written with the notion that the identifier
>>> was based around a "repository identifier" and thus tied to a single
>>> repository. I see two options:
>>> 1) do not check for unique registration of v2 oai-identifier
>>> repositoryIdentifier value in the OAI validator (this should probably
>>> be combined with a change in the specification to note that the term
>>> repositoryIdentifier has been kept only for historical reasons, already
>>> hinted at in section 2.4 of
>>> 2) require that only one repository using each identifier expose an
>>> <oai-identifier> description block in the Identify response.
>>> I don't think it makes sense for you to pick a dummy namespace.
>>> On Mon, 19 Dec 2005, Eloy Lafuente wrote:
>>>> I'm Eloy Lafuente, lead developer of http://dialnet.unirioja.es (and
>>>> scientific resources portal).
>>>> More than one year ago, we registered our:
>>>> With the identifier:
>>>> oai:dialnet.unirioja.es:ART0000001 (for example)
>>>> OAI server in your list of data providers. Such OAI provides access
>>>> to a lot
>>>> of full-text articles from scientific magazines and monographs.
>>>> In the last months we have added a new type of resource to our system,
>>>> Thesis. And we have built one separated OAI service in the same host:
>>>> With the identifier:
>>>> oai:dialnet.unirioja.es:TES0000001 (for example)
>>>> Some minutes ago, I was trying to test and register this new OAI
>>>> but the initial test fails because:
>>>> "The requested OAI repository name 'dialnet.unirioja.es' is already
>>>> registered to another base URL"
>>>> Reading your documentation about OAI identifiers, it seems that we
>>>> reuse the same 'dialnet.unirioja.es' as namespace-identifier in the
>>>> oai-identifier string (although, in our case, I think that it's REAL
>>>> situation, because both repositories are in the same host/machine).
>>>> So, the question is, how do we solve this? Is it ok to "invent" a
>>>> different namespace-identifier, say, 'tesdialnet.unirioja.es' in
>>>> order to
>>>> register our new provider? Is it the correct solution, knowing that,
>>>> in the
>>>> real world, the 'tesdialnet.unirioja.es' doesn't exist at all?
>>>> TIA, cheers and ciao, Eloy :-)
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
More information about the OAI-implementers