# Re: Re-write of (formerly) URM paper!

Olle Jarnefors (ojarnef@admin.kth.se)
Thu, 4 Nov 93 23:52:49 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Tim Berners-Lee: "Re: A spec for showing language in MIME headers"
- Previous message: Michael Mealling: "Re: Re-write of (formerly) URM paper!"
- In reply to: Michael Mealling: "Re-write of (formerly) URM paper!"
- Next in thread: Michael Mealling: "Re: Re-write of (formerly) URM paper!"
- Reply: Michael Mealling: "Re: Re-write of (formerly) URM paper!"

    Date: Thu, 4 Nov 93 23:52:49 +0100

    Message-Id: <9311042252.AA11694@othello.admin.kth.se>

    From: Olle Jarnefors <ojarnef@admin.kth.se>

    To: uri@bunyip.com

    In-Reply-To: <9311040339.AA02103@fuzzl.oit.gatech.edu.noname> (Wed, 3 Nov 1993

    Subject: Re: Re-write of (formerly) URM paper!

> Michael Mealling
> Michael.Mealling@OIT.gatech.edu
> Georgia Tech
> October, 1993
>
> Uniform Resource Characteristics

Michael,

Here are some comments:

> NOTE: There has been some violent disagreement with the above statement
> concerning multiple URNs in the same URC. It is only offered for comment.
> Nothing is lost by disallowing multiple URNs and only a small gain is
> accomplished. Take it or leave it...

A naming authority may decide to assign different URNs to
two documents with almost the same intellectual content but
different formats. A PostScript version may contain prettier
figures than the plain text version where crude "ASCII graphics"
is used, while the text is the same. In such cases most of the
meta-information about both documents will be the same and it
seems reasonable that one URC can be used to describe both
documents.

Another reson to allow more than one URN in a URC is that
different naming authorities may give URNs to the same resource.

> 3.3.1 URI Rules of Precedence
>
> In order for the numerous UR* in a URC to make sense, there must be order to the
> sequence of items. The order that makes the most sense is based partly on
> expected time to live and partly on an arbitrary precedence scheme. A URN is
> meant to be unique over all time and eternity; therefore, the first occurrence
> of a URN must have precedence over all other UR* in that URC. A URL is meant
> to be unique to the location of the document. The document itself may change,
> which would cause its meta-information to change, but not it's URL. Thus, a
> URL has precedence over a URC. ...
^^^
Here you must mean "a piece of meta-information" rather than
"a URC". In my proposal for the syntax of URCs I used _URD_
(Uniform Resource metaData descriptor) as a short name for this
kind of URC element.

> ... therefore, the first occurrence
> of a URN must have precedence over all other UR* in that URC. ...
> - - -
> ... Finally another occurrence of a URN denotes a new resource that
> has precedence over subsequent UR* in the URC.

I suggested explicit markers for grouping URNs/URLs/meta-pieces
in my proposals, but using precedence rules is another possible
solution. I'm not quite sure that I understand your exact rules,
though. Take this URC as an example:

Meta0
URL1
Meta1
URN2
Meta2
URL21
URL22
Meta21
URL23
Meta23
URN3
Meta31
URL3
Meta32

I would say that its structure is as indicated by indentation
here:

Meta0
URL1
Meta1
URN2
Meta2
URL21
URL22
Meta21
URL23
Meta23
URL24
URN3
Meta31
URL3
Meta32

In this case thus three resources are cited: URL1, for which no
URN is known, and URN2 and URN3. Four URLs are given for URN2
and one URL for URN3.

Meta0 is valid for all three resources. Meta1 is valid for URL1
only. Meta2 is valid for URN2 for all its URLs. Meta21, however,
is only valid for URL21 and URL22 (which are fully equivalent in
this case), Meta23 is only valid for URL23. For URL24 no extra
meta-information is known. Therefore it must be placed last
among the URLs for URN2.

As a degenerated case, both Meta31 and Meta32 are valid for
URL3.
Does this interpretation of the URC agree with your intentions?

> Also, a URC does not need 1 or more of any URN, URL or URC to be a URC. A
> URC can be made up of just URLs and meta-information without a corresponding
> URN. Conversely, a URC can have only URNs and URLs, or just URNs, or just
> URLs, or even just a collection of meta-information. You can even have a null
> URC which contains nothing.

Another special case is a URC consisting of a single URN or a
singel URL. This makes it tempting to have only one wrapper
defined, for URCs. It could be a "<" at the start of the URC and
a ">" at its end. Isolated URNs and URLs would then
automatically get the same wrapper. When included as a part of a
URC containing other elements, the URN/URL would need no wrapper
of its own.

> The problem of standardizing meta-information tags in the template format is a
> VERY thorny problem. ...

Not only meta-information tags but also the syntax of the meta-
information values for a certain tag needs to be standardized.
To look at the previous example

> URN:1:IANA:626::Dir:6345
> Author: Michael Mealling
> Subject: OIT Computing Resources
> URL:gopher://gopher.gatech.edu:2048/11/Computing.Resources
> Cost: US$0.00

the Author: field is problematic because it's not made explicit
which part of the name is most significant. In e.g. Hungarian
and Chinese the first part of a personal name is the family
name, the second part is the given name. For names like the
Danish "Per Brinch Hansen" it's not easy to know for sure if
"Brinch" is the second given name or the first part of a double
surname.

In the Cost: field it would probably be better to prescribe use
of the international currency codes of ISO 4217, in this case
"USD".

> ... Currently the author believes that the IAFA templates with
> the Non-Existant Data Elements Working Group modifications are some of the best
> work in this area ...

It's a pity that the work on data elements obviously is
performed by a secret group that doesn't publish its preliminary
results as Internet drafts.

/Olle

    --
    Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef@admin.kth.se>

- Next message: Tim Berners-Lee: "Re: A spec for showing language in MIME headers"
- Previous message: Michael Mealling: "Re: Re-write of (formerly) URM paper!"
- In reply to: Michael Mealling: "Re-write of (formerly) URM paper!"
- Next in thread: Michael Mealling: "Re: Re-write of (formerly) URM paper!"
- Reply: Michael Mealling: "Re: Re-write of (formerly) URM paper!"