[OAI-implementers] OAI identifier resolver

[Xiaoming Liu]

On Tue, 21 Oct 2003, Young,Jeff wrote:

>
> I think the concern about algorithmically assigned repositoryIdentifiers is
> overstated. If someone cares to give a specific example of where it's a
> problem, I'm sure we can work out something reasonable.

I try to give an example. Let's say if a service provider wants to link
each record to POI, how could it construct the URL? it doesn't have prior
knowledge of which repository is supported by POI, nor how the
repositoryIdentifier is maintained by POI. So it has to learn the mapping
table (repId<->baseURL). I don't know if there is an API to list mapping
table of PURL, otherwise, this may require offline communication.

Even POI mapping table can be easily available, other service
providers/resolvers may maintain their own mapping table. I don't see an
easy way to keep a single mapping table without centralized control.


xiaoming



>
> Jeff
>
> >  -----Original Message-----
> >  From: Xiaoming Liu [mailto:liu_x@cs.odu.edu]
> >  Sent: Monday, October 20, 2003 9:41 PM
> >  To: Lonnie D. Harvel
> >  Cc: OAI-implementers (E-mail)
> >  Subject: Re: [OAI-implementers] OAI identifier resolver
> >
> >  This is back to the problem why we need a resolver. If both
> >  baseURL and
> >  record identifier are supplied, it doesn't make a lot sense
> >  to develop a
> >  resolver. I think the motivation is to provide a "cool" URL for each
> >  record, and make it easy to exchange information by REST model.
> >
> >  OAI has no centralized mechanism to maintain unique
> >  repository name, it's
> >  either done by one centralized registry -- like UIUC
> >  registry, or done
> >  by a distributed way -- like hashing baseURL or other better
> >  ways. In the
> >  distributed way, I can add a link to Purl-OAI resolver without prior
> >  knowledge of how repository name is maintained in Purl-OAI resolver.
> >  That's my reason of favoring distributed method.
> >
> >  xiaoming
> >
> >
> >
> >
> >
> >  >
> >  > Adam Farquhar wrote:
> >  >
> >  > > Xiaoming,
> >  > >
> >  > > Selecting an approach that will be certain to fail, but
> >  unpredictably,
> >  > > is not a good 'engineering' approach, especially when
> >  there are other
> >  > > approaches that do not fail.  For example, taking a
> >  base64 encoding of
> >  > > the base URL or just using the base URL itself will both
> >  provide a
> >  > > unique identifier.
> >  > >
> >  > > Adam.
> >  > >
> >  > >>>Hash algorithms such as MD5 or CRC32 cannot be used to
> >  generate unique
> >  > >>>identifiers.  These algorithms will occasionally
> >  produce the same output for
> >  > >>>different input strings (this is why hash tables
> >  require a mechanism for dealing
> >  > >>>with collisions).  Common approaches to generating
> >  unique identifiers use some
> >  > >>>sort of a registration mechanism to appropriately
> >  partition the space of possible
> >  > >>>values.  Successful ones will leverage an existing
> >  registration mechanism, such
> >  > >>>as DNS.
> >  > >>>
> >  > >>>
> >  > >>
> >  > >>I agree hash algorithm is not a "perfect" way to generate unique
> >  > >>identifier for a repository, but it may be acceptable in
> >  engineering
> >  > >>perspect, the collision possibility will be pretty low
> >  in current scale of oai data
> >  > >>providers (<500?).
> >  > >>
> >  > >>I think the basic problem is how to render OAI baseURL
> >  to a shorter,
> >  > >>readable string in non-collision way. The algorithm
> >  should be repeatable
> >  > >>-- Anyone can use same algorithm to generate same output
> >  given a baseURL.
> >  > >>I will be glad to see other approaches.
> >  > >>
> >  > >>
> >  > >>
> >  > > _______________________________________________ OAI-implementers
> >  > > mailing list List information, archives, preferences and to
> >  > > unsubscribe:
> >  > > http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> >  >
> >  >
> >  >
> >
> >  _______________________________________________
> >  OAI-implementers mailing list
> >  List information, archives, preferences and to unsubscribe:
> >  http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> >
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>
>