Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs

[At the moment, the trend would seem to be that URI stays..
so I am reducing the distribution a little because this
is detailed stuff on the URL/URN harmonization agenda...]

to follow up on what Larry Masinter said:

> Some URLs don't accept relative references, e.g., 'cid:' and
> 'mid:'. Maybe these should be URNs, too, but they're used
> to locate a resource in a message, not to name it. So it's
> fuzzy.
> 

Various of the schemes now called URLs make more sense as names
than as locators.  

And relative references such as 'ibid' and 'loc_cit' abound in
the natural-language reference vocabulary we should try to serve
in URNs.  Referencing the previous article in a document
published as a series of journal articles is a natural
application for relative references in a namespace, as is
referencing an article in the previous issue of the same
periodical.

> I think fragment identifiers that are used for *named* fragments
> are useful in URNs and URLs equally. If fragments
> were used as locators with some syntax "#bytes:1-47", we'd
> have more of a problem.
> 

[response 1 -- fragments as we know them]

The general URL syntax draft wisely avoids trying to give a
uniform concept or specfication for the the interpretation of
#fragment substrings in URL references.

Note that the "fragment" in this syntax symbol should therefore
be read as "this fragment of the textual URL-reference," not "the
cited fragment of the referenced resource" even though in the
common case of http: URLs referring to HTML documents either
interpretation fits.

Given this level of caution in the URL spec, I see no way to
claim that the concept doesn't translate into the URN domain.
The concept is that you want to make a reference on a finer
grid than the retrieval-chunking-factor of the resource.

The object class of the object that you are naming can define
what indexing methods it supports. You can use a #fragment phrase
in UR* references for consistency and require that #fragment
strings in schemes in the URN subseries are to be interpreted in
accordance with published profiles for the class of the named
object.

The concept applies just fine to named information items.
Whether you want to use the #fragment syntax is still up to you.

[response 2, extensions pending]

Both Dan Connolly and I have independently opined in the past
that it should be possible for a third party to make a reference
into a resource with a string-to-match, a line-number, or 
something objective that the resource author didn't necessarily
mark as special.

Line numbers are inappropriate in text/html but string matches
are appropriate.  Line numbers are fine e.g. in FORTRAN files
where newlines are significant.

A named object that is polymorphic across languages might not
accept string matches but might accept section numbers.  Or it
might accept strings in conjunction with a language parameter.
Etc.

I still have hopes to see this kind of intra-resource reference
refinement strengthened in the URI vocabulary of the 'Net.

See for example my flame about "Where-it-says in URLs" at

  http://www.access.digex.net/%7Easgilman/web-access/wis_rfc.html

-- Al Gilman

Received on Friday, 24 October 1997 18:07:53 UTC