Re: [metadataInURI-31] A guide to where we stand on issue metadataInURI-31

On Mar 28, 2006, at 7:05 AM, noah_mendelsohn@us.ibm.com wrote:

> last week we decided to have a more balanced presentation of the  
> upsides
> and downsides of relying on inferred metadata.  In particular, we all
> regularly manipulate URIs based on guesses involving metadata.  For
> example, after somehow discovering a link to:
>
> http://example.org/book/chapter2
>
> many of us will quite reasonably experiment with trying to find  
> chapter 3
> at:
>
> http://example.org/book/chapter3
>
> even if we haven't checked what the publishers actual URI assignment
> policy is.  If the document retrieved by that URI looks right, we may
> trust it.  Of course, you wouldn't use such a guess when requiring
> information that's 100% reliable, but in many cases it's a good an  
> useful
> thing to do.   It's an important aspect of what people expect of  
> the Web.

Umm, yes, but that isn't metadata about the resource.  The 2 and 3
are essential parts of the identifier.  The finding should be about
non-identifying data included in the URI, which is almost always stuff
that is metadata about actions on that resource.

Hmm, I know I've sent this message before .... oh, it was private mail.
Here is what I wrote on May 23, 2003:

   Message-Id: <ECAFA7D8-8D64-11D7-A116-000393753936@apache.org>

   I think it needs more work.  We need to distinguish between metadata
   and identifying information.  Versioning, for example, is identifying
   information and does belong in the URI iff the resource is that
   specific version.  The reason we rejected the request was not because
   it isn't identifying information -- it is because there is no need
   for a single standard on how the origin identifies versions.

   Metadata, OTOH, is ancilliary information -- what is identified does
   not change with or without the metadata.  As such, its presence  
causes
   the number of possible identifiers per resource to explode.  Having
   too many identifiers for the same [resource] causes all sorts of  
havoc
   with caching, access control, etc.

   Finally, the opacity principle is not saying that servers should not
   include meaningful information in the URI -- it is saying that  
clients
   should not derive meaning by inspection of the URI.  Note, however,
   that the opacity principle is scheme-dependent -- it is not true for
   ftp and file schemes, among others.

   I'd suggest more, but I really need to finish the URI specification,
   particularly since this finding is dependent upon that.

....Roy

Received on Tuesday, 28 March 2006 18:55:16 UTC