# Re: date in URN

Terry Allen (terry@ora.com)
Sun, 25 Jun 1995 13:05:08 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Daniel LaLiberte: "Simple comparison of URNs"
- Previous message: Larry Masinter: "Re: More comments on the mailserver URL scheme"

    From: "Terry Allen" <terry@ora.com>

    Message-Id: <9506251305.ZM26192@dmg.west.ora.com>

    Date: Sun, 25 Jun 1995 13:05:08 -0700

    In-Reply-To: Peter Deutsch <peterd@bunyip.com>

    To: Peter Deutsch <peterd@bunyip.com>, Mark Madsen <msm@ansa.co.uk>

    Subject: Re: date in URN

Peter:
| [ Terry Allen wrote: ]
| } <naming authority>:[<optional human readible string]>:<unique ID>
| } ===
| } but how does having a new readable string help me transcribe
| } the unique ID?
|
| Hmmm, good point - I guess it doesn't. I suppose in my
| confusion I was refering to something I might call
| "selectability", which would be the ability to select
| appropriate items either mechanically or by doing a little
| "wetware" processing on them. Still, as I sit in my office
| on a Sunday afternoon and I continue to think about what I
| mean here, perhaps I can claim that selectability enhances
| transcribability in some way? Or maybe, we really have a
| URC, not a URN and the URNs are going to disappear from
| view before they're even deployed?

No, but when you go to resolve a URN you may want to supply
additional information. In addition to supplying the ISBN URN for
some edition of "Frederic and Elfrida" I might also supply the
title and author, so that my local mechanism could use the info
that the author is Jane Austen to go not to OCLC or BIP but
instead to the Jane Austen URN server, which might be offered
by some service such as

http://uts.cc.utexas.edu/~churchh/janeinfo.html

and might be cheaper, closer, or more accurate (as determined by
experience or recommendation). Even if I go to OCLC I can perhaps
get a discount by supplying info that helps the resolution go faster.
In short, you use the context in which you discover the URN.

| As we've been using the term for the past four or five
| years in this community, a URN "name" is something that
| tells me about selecting a thing, rather than about about
| accessing that thing.

absolutely.

| If users can see a readible "human
| bit" or headline, it would help them to select the correct
| part and they might thus be more tolerant about systems that
| make them type in some bits that looks like line noise. So,
| a URN of the form:
| <URN:ISBN:"The Complete Fawlty Towers":0-413-18390-4>
| is probably preferable to:
| <URN:ISBN:0-413-18390-4>
| or a URL such as:
| <http://methuen.com.uk/catalogue/1988/fwty.html>

I don't see why. I'm going to cut and paste it anyway, or punch
a button that grabs the whole string. I do see that coupling
metadata with URNs makes a better reference, and that a really
good reference would resemble a bibliography entry plus URN.

| Note that I think even the second form of URN is
| preferable to the URL (since people in the book store
| already understand ISBNs and might be expected to learn
| about this new form of an old friend)

agreed.

| but the first is
| probably closest to something humans can grok and is
| closer to current publishing practice.

well, no. BIP is the URC collection for ISBNs of in-print books
published in the US. There, and in publishers's catalogues, one
sees ISBNs coupled with full biblio data. One the backs of books
you see ISBN:0-413-18390-4 and some bar coding (now that's truly
human nonreadable). The book itself provides context. (Typos are
guarded against by using a checksum for the last digit.)

| For mechanical
| systems such as Silk, you could display only the
| "headline" portion and leave the internal URN to the
| program. Is this really a URC? Maybe, in which case here's
| a real need for these things ASAP.

If someone says only "see URN:foo" he hasn't provided the context
you need. But let's not require that to be stuffed inside the
URN. It would better go in the link:
"see <a title="Frederic and Elfrida" href="urn:isbn:foo">"
or whatever the proper syntax is for your favorite URN scheme.
and it gets displayed that way.

| So, I guess it isn't spelled out in these terms in the
| functional spec, but if we map "comparision" to
| "selectability" and extend it to the idea that we might
| want to perform comparison not just between two URNs, but
| between a URN I have and what I know about it, then I
| still think we should consider the suggestion.

In which case you are comparing metadata, not URNs. Use the
URN to get the metadata if context doesn't supply it.

| BTW, in operation we can simply do the derefencing on the
| mechanical part of the ID, so typos in the title portion
| would not affect the outcome (as the store clerk does now
| when you ask for a book).

then would it not be reasonable to get on with it and specify
only that much?

| They should still be
| allowed/encouraged in the parts humans see since in our
| limited experience with Silk they seem to make these
| things more useful.

Yes. Context is good.

| So, for my previous postings where I mention
| "transcribability" please substitute "selectability" and
| see if it makes any more sense.... :-)

Then I think selectability is to be determined on the basis of the URC,
not the URN.

Regards

    --
    Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
    Editor, Digital Media Group    101 Morris St.
    			       Sebastopol, Calif., 95472

    A Davenport Group sponsor.  For information on the Davenport
      Group see ftp://ftp.ora.com/pub/davenport/README.html
    	or  http://www.ora.com/davenport/README.html

- Next message: Daniel LaLiberte: "Simple comparison of URNs"
- Previous message: Larry Masinter: "Re: More comments on the mailserver URL scheme"