RE: [metaDataInURI-31]: Initial draft finding for public review/c omment.

For me part of the question is when I (or a piece software I might write)
look at a URI (assigned by someone else), what do I allow myself to know
(intrinsically from examining the URI rather than going without asking an
authority)? (BTW "Nothing" is an acceptable answer). Do I allow myself
access to the knowledge embedded in a bunch of normative specifications (and
possibly published assignment policies)?
 
Do I allow myself to know that the URI  <mailto:skw@hp.com>
mailto:skw@hp.com identifies an "Internet mailing address", because RFC2396
(and successors) allow me to identify a scheme component and RFC2368 as the
registered scheme specification for the mailto URI scheme tells me "The
mailto URL scheme is used to designate the Internet mailing  address of an
individual or service". IMO, if I allow myself to know that
mailto:skw@hp.com <mailto:skw@hp.com>  identifies an "Internet mailing
address" then I have 'peeked', allbeit at only the scheme component.
Likewise for other URI schemes that state the sort of thing that they are
used to identify. Some would say, "No, you don't allow yourselve to know
such things... don't peek, URI are opaque (to a web client)." Others want to
build rule driven systems that very much depend allowing such inferences...
and it was only a little peek... hardly a peek at all... (maybe).
 
Another example, that links with the httpRange-14 debate. One position in
that debate is that http scheme URIs without fragment identifiers may only
be used to identify network accessible resources, and may not be used to
identify abstract concepts (eg. a particular emotion) or a real-world object
(like DanC's car or a person) eg. using http://people.example.com/stuart
<http://people.example.com/stuart>  to identify me would be frowned upon.
However, within this particular position, it is ok to identify abstract
concepts and real world artifacts with http scheme URIs that include a
fragment identifier ie. http://people.example.com#stuart
<http://people.example.com#stuart>  would be fine. If we were to accept this
particular position, then the presense or absense of a fragment component
(even a null fragment) in an http URI allows an inference to be made about
whether the referenced resource is a network accessible resource or an
abstract concept or real-world thing. Some folks want to build systems that
rely on such distinctions... and IMO this again is peeking. 
 
"Don't peek inside URI's" is a very simple thing to say and to understand,
but I think that even amongst those that might say it there is a temptation
to peek - with good reason - so as a prinicple it may be a little to
simplistic.
 
Regards
 
Stuart
--
 
-----Original Message-----
From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] 
Sent: 9 July 2003 10:13
To: MDaconta@aol.com; skw@hp.com; www-tag@w3.org
Subject: RE: [metaDataInURI-31]: Initial draft finding for public
review/comment.



 

-----Original Message-----
From: ext MDaconta@aol.com [mailto:MDaconta@aol.com]
Sent: 08 July, 2003 21:11
To: skw@hp.com; www-tag@w3.org
Subject: Re: [metaDataInURI-31]: Initial draft finding for public
review/comment.


In a message dated 7/8/2003 6:44:46 AM US Mountain Standard Time, skw@hp.com
writes:



I would appreciate some feedback on this draft. Whether a simpler, shorter,
finding is a better path to take? Whether "Don't peek inside URIs" is all
that need be said?




Hi Stuart,

First, to answer your questions:
1. A simpler and shorter finding is only better for the "don't peek inside"
position.
2. I disagree with the "Don't peek inside URIs" sentiment.  

The "Don't peek inside" position stresses the use of identification as an
assertion of 
uniqueness and possibly a mechanism to locate that unique thing.  In
essence, 
an opaque "pointer".  While those are necessary functions of a URI, 
imbuing an identifier with additional metadata should be 
encouraged.  First, additional metadata in a URI makes it 
easier to keep the URI "cool" (as in
<http://www.w3.org/Provider/Style/URI.html)>
http://www.w3.org/Provider/Style/URI.html) by
adding classification metadata to the identifier (as with the W3C URLs in
your 
finding). 
 

What if the metadata changes? Then you have a different URI, and things
break.
 
URIs with metadata embedded in them which might change are hardly "cool".


Second, additional metadata in a URI enables a higher-level
of efficient processing on resources by applications that *just* want 
to process URIs.  Opaque URIs would eliminate that increasing possibility.
 

There are better (ie. generalized, scalable, flexible) ways to provide
access
to resource descriptions than embedding such knowledge in the URIs that
denote them.
 
C.f. http://sw.nokia.com/URIQA.html <http://sw.nokia.com/URIQA.html> 
 
Cheers,
 
Patrick



--
Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
  


Best wishes,

- Mike
---------------------------------------------------
Michael C. Daconta
Chief Scientist, APG, McDonald Bradley, Inc.
www.daconta.net