PURLs -Reply -Reply

[weibel at oclc.org]

PURLs is an incremental solution to part of the name resolution
problem.  It is not intended as an alternative to, for example, the URN
Services proposal that we have advanced in the IETF working groups, but
rather, as one component of the architecture that will support the sort
of sophisticated cataloging and resolution environment that Vianne Sha
quite sensibly appeals for in her message (quoted below).

The problem with deploying URN schemes is that you have to have the
architecture in place before you can build the services.  The
underlying architecture for PURLs (HTTP) is already in place.  We will
build the necessary services in an evolutionary way, and we expect
others will, also.

Should we have waited for complete agreement on URNs before developing
these services?  A good question.  The problem of orphaned URLs is an
immediate problem for maintaining catalogs of internet resources (made
very clear in, for example, the Internet Cataloging Project
(www.oclc.org:6890).

While there is convergence in the URN discussions, it is not clear that
a  solution will be deployed in the near future (by solution, I mean
links in documents that work, for example).   The PURL solution works today
and all the services built around it will work in a world that has
ideal URNs as well.  None of what we are building is in conflict with
the consensus we are helping to forge in the URN arena.

The OCLC PURL Team

Erik Jul      jul at oclc.org
Eric Miller   emiller at oclc.org
Keith Shafer  shafer at oclc.org
Vince Tkac    tkac at oclc.org
Stu Weibel    weibel at oclc.org

-------------------------------------------------------------------------

Vianne Sha writes:

> OCLC has implemented PURL as a resolution to the persistence problem
> of the URLs.  It helps maintaining the accuracy of URLs in our
> catalog records.  I believe it will work well in our current
> situation (I have NO intention in opposing OCLC's PURL scheme using
> in InterCat project).

> Since there is a URN resolution standard proposed in response to IETF
> RFC 1737 (4 existing schemes as of December 95: Handle, x-dns-2, Path
> URN, and OCLC), I wonder why OCLC does not implement the resolution
> for one URN to a list of URLs extracted from a URC, which was
> proposed as one of the resolution methods in the OCLC URN scheme?  In
> the meantime, PURL's structure will work for InterCat.  However, in
> the long run, it is better to have all URLs linked to one URN,
> applying the concept of authority record.  OCLC's scheme is the most
> flexible scheme that may work with other proposed schemes.  I would
> ike to see OCLC implement the best resolution.  Other proposed
> schemes have their advantages and may work well in some settings.  If
> OCLC can work with these groups to develop a comprehensive and
> sophisticated scheme, we might have a standard to maintain the URLs.