# Re: URC's

John A. Kunze (jak@violet.berkeley.edu)
Wed, 6 Apr 1994 11:24:10 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: Seattle minutes"
- Previous message: Michael Mealling: "Re: URC's"
- Maybe in reply to: Karen R. Sollins: "URC's"
- Next in thread: Karen R. Sollins: "URC's"
- Reply: Karen R. Sollins: "URC's"

    Date: Wed, 6 Apr 1994 11:24:10 -0700

    From: jak@violet.berkeley.edu (John A. Kunze)

    Message-Id: <199404061824.LAA08273@violet.berkeley.edu>

    To: sollins@lcs.mit.edu, uri@bunyip.com

    Subject: Re: URC's

> Date: Tue, 5 Apr 94 19:41:49 -0400
> From: "Karen R. Sollins" <sollins@lcs.mit.edu>
>
> I don't know whether this will clear the air or only make it murkier,
> but let me try this.
>
> First, about the "name". Originally, Michaal, I believe, proposed
> that the "C" was for "citation". I believe (correct me if I'm wrong)
> ...

For the latecomers, the first use of URC was as "citation".
The enclosed mail message from Nov. 1992 explains it best.

> I suggested later that we extend
> that concept by using "C" for "characteristic" because I was trying to
> generalize the concept.

Hmm. We're comfortable with URN as some strange kind of "name".
We're comfortable with URL as something based on a "location",
but which goes beyond it to include essentially "access scripts".

Yet we're uncomfortable with URC as a generalization of "citation"?
I don't get it. Is there something inherently limiting about that word?

Even in the paper world, "citations" take on many different forms --
mutating, adding new fields, etc. to meet the demands of the application.

-John

=========================================
>From jak Tue Nov 3 19:45:34 1992
To: ietf-url@merit.edu
Subject: URLs and beyond

I think that Tim's URL documnet is very valuable in delineating many
important issues. We're stuck/blessed with a mix of protocols for the
near future so we might as well make the most of it. I've been running
a Z39.50 client and server (not WAIS) for about a year now and believe
that URLs will be crucial for document retrieval on our system.

For me, however, URLs don't go far enough, and I'd be interested to know
whether my points resonate with other info systems implementors.

What I think we need might be called a Uniform Resource Citation (URC).
URCs would turn up mostly as hypermedia links (e.g., within documents).
They or their semantic equivalents would be returned in database records
(e.g., Z39.50). Each URC would contain six components:

1. A URL to identify the resource (document, database, telnet session, etc.).
Decomposition rules allow the derivation, say, of a server URL
from a database URL as well as construction of full URLs from
partial URLs (i.e., I'm in favor of URLs relative to a hierarchy).

2. A Uniform Fragment Specifier (UFS) to identify a subpart of the resource.
The name "UFS" is made up to suggest a generalization of Tim's
Anchor-ID. It is protocol and implementation independent (maybe
only because a protocol ignores it). Decomposition rules allow
derivation of less specific fragments from more specific ones.

Client Software Requirements:
The client needs 1 and possibly 2 to access the resource.
Unfortunately, the client also needs 3-6 below to make an adequate
user interface.

3. A Unique Resource Serial Number (URSN) to filter duplicates.
[ NOTE: these are now called URNs ]
Peter Deutsch has made a case for URSNs. Clients and gateways can
use them to save users from being buried in lots of redundant hits.

4. An access list to publicize restrictions.
In general a server will restrict access to subsets of its data.
Sometimes a client does well to suppress a link's existence if it
knows you can't access it; on the other hand, the client that knows
you can't access it may want to prompt you to authenticate yourself.
In both cases, the software needs to know who can access it. Human
being need to know it too, in case they decide to pursue access.

No access list is also a problem for data provision. For example,
in a hierarchical hypertext-based campus information system, nodes
are maintained by autonomous departmental units without a high
degree of computer sophistication. Review of pre-release or test
data is best done by these providers in a context as close as
possible to the final production context. Access privileges
attached to the links would allow them to review restricted data
that is actually *in* the production context; the alternative is to
build and maintain a duplicate hypertext hierarchy for each provider.
(This example seems a bit too involved, but I'm sure there's a
point in there somewhere...)

5. A functional type for the citation or hypermedia link.
Besides being a useful search field, this lets the user interface
construct semantics like "click here to see this document" or "click
here to search this database". Note that it is *not* always possible
for a client to determine functional type from the URL because some
or all of a URL may be opaque to the application layer. For example,
"telnet" is sometimes used "functionally" to fetch small documents
without any user interaction (e.g., a weather server).

6. Human-readable descriptive fields to identify the link later.
We should expect clients and users routinely to collect, organize,
edit, and save lists of links for later use. This is what people
do now with bibliographies. When you come back to a URL an hour
after you plucked it out of its context, chances are you have no
idea what it points to. Now you direct your client to browse that
list of URLs you saved yesterday, which is about as useful as
(and very analogous to) browsing a list of library call numbers.
In order for you to make an intelligent selection, your client
needs to de-reference every link in the list to pull back
identifying information (e.g., with the URSN, if applicable).

The descriptive fields should include the minimum distinguishing
properties most useful for user selection and most painful to
collect through de-referencing if they were absent. Fields like
Name, ModificationTime, and Size are a good candidates.

Descriptive fields would often be supplied by the data provider.
This could relieve the hypertext document provider from manually
describing the link in text, and changing that text as it gets
out of date.

The analogy between URCs and tried-and-true bibliographic citations is
obvious and not new. My point is that URLs are great but only as useful
as library call numbers are relative to full citations, which have proved
their worth long ago. URCs and citations both exist both within text and
separate from text (e.g., in end notes and in database records). More
importantly, they both provide users with vital discriminating information
with which to optimize retrieval.

-John

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John A. Kunze 510-642-1530
Information Systems and Technology Fax: 510-643-5385
289 Evans Hall Internet: jak@violet.berkeley.edu
Berkeley, CA 94720 Bitnet: jak@ucbviole.bitnet
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

- Next message: Michael Mealling: "Re: Seattle minutes"
- Previous message: Michael Mealling: "Re: URC's"
- Maybe in reply to: Karen R. Sollins: "URC's"
- Next in thread: Karen R. Sollins: "URC's"
- Reply: Karen R. Sollins: "URC's"