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

Michael Mealling (ccoprmm@oit.gatech.edu)
Thu, 4 Nov 93 23:27:43 EST

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

    From: ccoprmm@oit.gatech.edu (Michael Mealling)

    Message-Id: <199311050427.AA25816@oit.oit.gatech.edu>

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

    To: ojarnef@admin.kth.se (Olle Jarnefors)

    Date: Thu, 4 Nov 93 23:27:43 EST

    In-Reply-To: <9311042252.AA11694@othello.admin.kth.se>; from "Olle Jarnefors" at Nov 4, 93 11:52 pm

Olle Jarnefors said this:
> > 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.

I think those that violently disagreed could just make the next
occurence of a URN a file delimeter. I agree that you gain by allowing
it but if it's going to cause folx to dismiss the whole concept I'd rather
drop it. If you don't mind I might add your examples to the paper as
examples of reasons why.

> > 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.

Correct. I did some creative search and replace on the original document.
I guess that one just slipped though. The reason I didn't give the
meta-information a name is because many members of the mailing list
are suffering from TLA overload. I received several comments to the
effect that readers eyes kind of went glassy when they saw all of my
TLAs. ;-)

> 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?

Whew...good example. Yes it follows except that you add that Metax
describes ALL URLs above it that don't have their own overriding Metax.
I would be warry of this since it makes the precedence retroactive up
the structure of the URC. I'll have to think on that specific case.
Beyond that I think that is a very good analysis.

> 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.

Correct. I didn't add this quite yet since the Working Group hadn't really
decided on the concept of wrappers yet. I think I'll wait on that
concensus before I add it to the paper.

> 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.

Correct. I would simply punt this back to the IAFA and MNEDE-WG
(Mythical Non-Existant Data Elements Working Group) ;-) I don't know
the answer to this and I don't think anyone does. It's a bitch of a problem
that I don't think any one group is going to be able to complete.

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

Correct. I just couldn't remember that spec.

> > ... 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.

Actually they did at this IETF. The categorically called it a failure but
decided on some things to work on for the future. I think that
the Data Elements group isn't dead but will be incorporated into some
psuedo-hybernating Working Group. I'll punt to the IESG on that one.

Thanks for the comments. I meant to put some references to your paper in
there but couldn't find it on the net. Do you have your paper in an
FTP archive somewhere?

-MM

    --
    ------------------------------------------------------------------------------
    Michael Mealling                     ! Hypermedia WWW, WAIS, and gopher will be
    Georgia Institute of Technology      ! here soon via MIME. Your view of the
    Michael.Mealling@oit.gatech.edu      ! internet is about to change completely!

- Next message: Olle Jarnefors: "Re: Re-write of (formerly) URM paper!"
- Previous message: Nathaniel Borenstein: "Re: A spec for showing language in MIME headers"
- In reply to: Olle Jarnefors: "Re: Re-write of (formerly) URM paper!"
- Next in thread: Olle Jarnefors: "Re: Re-write of (formerly) URM paper!"
- Reply: Olle Jarnefors: "Re: Re-write of (formerly) URM paper!"