Re: Comments on "URN Services"

We thank Dr. Renato Iannella for his thoughtful comments on our proposal.


> Some comments on the Internet Draft by Shafer (et al)
> "URN Services" (draft-shafer-uri-urn-resolution-00.txt)
> 
> 1 - The syntax and structure for URNs has changed !
>     I was under the impression (from "Generic URN Syntax"
>     internet draft) that a URN consisted of:
> 
>       naming-authority:resolution-host:opaque-string
> 
>     The new proposal seems to be:
> 
>       urc-type:resolution-host/naming-authority/opaque-string

There is currently no syntax and structure for URNs.  Our proposal
is one of several competing proposals.

Ours is:

   service-type:Optional_resolution_path/Naming_authority/Opaque_string
 
> 2 - I can see the need to be able to specify a "type"
>     of URC to be returned. I would prefer to see:
> 
>       urn:urc-type:naming-authority:resolution-host:opaque-string
> 
>     Each urc-type would be defined in an internet-draft like
>     "Trivial URC Syntax: urc0"
>     The opaque-string would point the the "full" URC of which the
>     urc-type would be returned (if many types are supported by 
>     the resolution service).

I believe we simply disagree about terminology rather than substance
here.  We view a URC as a record, and a variety of projections or views
of that record will be possible, each of which is accessible via a
service of known behavior.

> 3 - What is the reason for a URL to URC service? It sounds
>     likes a nightmare to maintain. It may even allow users
>     not to ever assign a URN ?

The mapping of URNs and URLs via URCs will indeed be  a challenging
task.  It is exactly the sort of thing done today by centralized
cataloging organizations.  It will be necessary in the electronic world
as well. One very important use of a URL to URC service is to search
existing collections of URCs to determine if a particular object
already has a URC (thereby reducing the production of duplicate URCs.

> 4 - In the URN to URL service it says that a single URL should
>     ultimately be returned. What if I have a URN that identifies
>     the Technical Reports written by my organisation:
> 
>       urn:urcXX:x500:uri.dstc.edu.au:c=AUo=DSTCuri=TechReports
> 
>    I would like this to return a list of URLs of all our
>    tech reports:
> 
>       ftp://ftp.dstc.edu.au/tech-report/resource-discovery.ps
>       ftp://ftp.dstc.edu.au/tech-report/distributed-systems.ps
>       ftp://ftp.dstc.edu.au/tech-report/z39.50-report.ps
> 
>    Should there be a "URN to URLS" service ?
>    (This is related to point 2 above)

A URN may well (often will) map to a collection.  But clicking on a
link should NOT return all objects in such a collection, but rather a
surrogate record representing the collection (for example, am HTML list
of the URNs or URLs associated with the componenents of the record).

But yes, there will be a URN to URLs service, because it will be useful
to ask the question, "What are all the known URLs associated with a
particular object?"  Its just that this is not the *default* service.

Part of the point of our proposal is that we need not imagine all the
services ahead of time... we're not smart enough.  The system must
accomodate growth in functionality.

stu

Stuart Weibel
Senior Research Scientist
OCLC Office of Research
weibel@oclc.org
(614) 764-6081 (v)
(614) 764-2344 (f)
http://www.oclc.org:5046/~weibel

Received on Wednesday, 7 June 1995 08:07:37 UTC