Re: URIs for Physical Items

Howdy,

I'm not going to speak to the "physical item" issue, but rather the
"URL/URI" usage here.

"Paskin, Norman (DOI-ELS)" wrote:
> make. I think obfuscating URLs and URIs does not help the discussion. I
> simply use URLs as the guy in the street understands that term: what he sees
> on the side of a bus.  Because thats all thats out there on the web for all
> practical purposes right now.

What "they guy on the street" thinks of URLs, and thinking of URLs
as something uniquely tied to the world wide web Internet application
are the obfuscation.

From

http://www.isi.edu/in-notes/iana/assignments/url-schemes

here are just a few currently implemented, deployed, and heavily
relied-upon URL schemes that (I honestly hope) will never be found
on the side of a bus:

Scheme Name     Description                                    Reference
-----------     -----------------------------------------      ---------
ftp             File Transfer Protocol                         [RFC1738]
mailto          Electronic mail address                        [RFC2368]
news            USENET news                                    [RFC1738]
nntp            USENET news using NNTP access                  [RFC1738]
telnet          Reference to interactive sessions              [RFC1738]
file            Host-specific file names                       [RFC1738]
cid             content identifier                             [RFC2392]
mid             message identifier                             [RFC2392]
nfs             network file system protocol                   [RFC2224]
data            data                                           [RFC2397]
sip             session initiation protocol                    [RFC2543]

While some or all of these might be found in HREF's (hey, that's
the beauty of having a URL syntax), they are built for specific
applications -- e.g., SIP, which I've seen on business cards, which
will primarily be useful in Internet telephony applications (e.g.,
from phone interface applications).

> and lots of things.  And I think URLs don't always do that (e.g. identify
> clases; enable identifcation of multiple copies).  And (here goes) I think
> URIs may do, -  but right now are too woolly in their definition and not yet
> widely practically implemented other than in the case of that subset of URIs
> which are URLs... and I know I will be assailed from all sides for saying
> that so i will now  retreat to the W3C URI activity which is meant to
> address some of these issues.

To follow up on the SIP url example -- it identifies an Internet
resource capable of handling session-based transactions.  The SIP
protocol itself defines how to determine the capabilities of the
identified resource, and to set up the appropriate session.

If you hold that example in mind, the notion of retroactively
imposing a definition of how to handle "classes, multiple copies",
etc, upon all URLs should seem a little more challenging, and perhaps
less advisable.  Those desiderata simply don't hold for all URLs
(not just the subset that might appear on buses).

If, however, you are only interested in the "document-like objects"
that can be referred to in the Internet, and the services needed
thereupon, it might be more advantageous to look elsewhere than
at the URL syntax/semantics, and address document-like-resource
issues in common metadata (sigh) and services.  

Leslie.

-- 

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary... 
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------

Received on Friday, 27 October 2000 09:38:20 UTC