# Re: URC proposal for Davenport Group

Daniel W. Connolly (connolly@hal.com)
Mon, 23 Jan 1995 13:50:29 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: URC proposal for Davenport Group"
- Previous message: Dirk Herr-Hoyman: "Re: URC proposal for Davenport Group"
- In reply to: Dirk Herr-Hoyman: "Re: URC proposal for Davenport Group"
- Next in thread: Michael Mealling: "Re: URC proposal for Davenport Group"
- Reply: Michael Mealling: "Re: URC proposal for Davenport Group"

    Message-Id: <9501231950.AA21020@ulua.hal.com>

    To: hoymand@gate.net (Dirk Herr-Hoyman)

    Subject: Re: URC proposal for Davenport Group

    In-Reply-To: Your message of "Mon, 23 Jan 1995 14:21:38 EST."

                 <ab4a11c40d0210045e62@[199.227.1.142]>

    Date: Mon, 23 Jan 1995 13:50:29 -0600

    From: "Daniel W. Connolly" <connolly@hal.com>

In message <ab4a11c40d0210045e62@[199.227.1.142]>, Dirk Herr-Hoyman writes:
>At 5:54 PM 1/23/95, Daniel W. Connolly wrote:
>>I think I'm missing something. You want it so:
>>
>> * the user to selects a ULINK
>> * the browser uses info from the ULINK to find another document
>> * that document is displayed
>>
>>Where does the URC and the bibliographic database come in? As far as I
>>can tell, the browser just takes a URL from the ULINK, decodes it into
>>a server and path as usual, and sends the path to the server. The
>>server looks up the path (ok... this could be some sort of database
>>lookup: is this the piece you want to explore?) and returns an SGML
>>entity.
>>
>I believe what is missing here in Terry's example is a URN or Uniform
>Resource Name. The URC is meant to be the "glue" that holds together URNs
>and URLs. Instead of using URLs as the ulink, one would use a URN, which
>is a location (and maybe format, language, ...) independent name. Then, a
>URN resolution server is queried, much like a DNS server, and returns a
>URC. The URC holds 0 or more URLs, as well as select other meta-data.

Ahhhhrrrg! If I see this unmotivated bunch of mumbo-jumbo one more
time I'm gonna go nuts!

WHAT is the TESTABLE distinction between this thing you call a URN,
and the currently deployed architecture for URIs? In what way is an
http URI not location independent? Where is microsoft.com? That's not
a location; it's a domain. It can be _anywhere_. How is it not format
independednt? How is it not language independent?

If http: URIs don't cut it (for performance reasons, for example),
then go ahead and make up a new scheme. No need to make up a whole new
identifier syntax. And I _still_ don't understand what features
they're looking for in URNs that aren't covered by the existing
architecture (except replication and authenticity, which are not part
of Terry's proposal). And most of the scenarios I've seen can be done
just fine with http.

>So, a URC comes together with a bibliographic database because they both
>hold meta-data.

More mumbo jumbo. Someone please give a precise defintion of
meta-data. I understand terms like "relational database," "inverted
index," "SQL," "precision," "recall." The term meta-data doesn't mean
anything in particular to me.

>I'll rephrase Terry's example now as:
>
><ulink uri="urn:microsoft:doc/windows3.1/userguide">
> Windows 3.1 User's Guide</ulink>
>
>And the associated URC could be
>
><urc>...

Why not just write:

<ulink uri="http://www.microsoft.com/doc/windows3.1/userguide">
Windows 3.1 User's Guide</ulink>

or if you find HTTP lacking, write:

<ulink uri="davenport://microsoft.com/doc/windows3.1/userguide">
Windows 3.1 User's Guide</ulink>

I can't believe you're going to make up a namespace to replace DNS. If
I were a publisher, and I wanted to do anything on the internet, the
first thing I'd do is register a domain. It's cheap, easy, and
necessary for many of the things I'd want to do. Parties that do
business on the internet in any way are going to register a domain. I
think that's a given. Why not take advantage of that namespace? At the
outside, you might want to do something like MX records to add some
indirection to DNS. But I haven't seen anything in Terry's scenario
that warrants that.

>And the associated URC could be
>
><urc>...

>You may or may not care for the syntax of this URC, but I hope the intent
>is clear.

It is not at all clear. What is the URC used for?

>There are many practical considerations here, such has just how does the
>URN resolution server work, what protocol does it use.

My question is why should it exist at all?

> But, the main point
>we are exploring at the moment is whether it makes sense to use SGML to
>encode the URCs. If we are to live in an increasing SGML oriented document
>world, then this would be a nice touch, since the URC could be contained
>within the document itself, as well as on a URN server. Makes harvesting
>the URCs a conceivable task.

Harvesting URCs... there's a notion that we might reasonably discuss.
If there's some part of the architecture (such as Harvest's technique
of shipping index information in bulk between gatherers/caches/brokers)
that requires sending URCs around, then that's motivation to define
a data format. Now we're into the resource discovery problem.

But terry's proposal only involved mapping identifiers to SGML entities.
For that, nothing beyond HTTP is necessary.

Dan

- Next message: Michael Mealling: "Re: URC proposal for Davenport Group"
- Previous message: Dirk Herr-Hoyman: "Re: URC proposal for Davenport Group"
- In reply to: Dirk Herr-Hoyman: "Re: URC proposal for Davenport Group"
- Next in thread: Michael Mealling: "Re: URC proposal for Davenport Group"
- Reply: Michael Mealling: "Re: URC proposal for Davenport Group"