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

Roy Fielding writes:

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

Why?  Using an example from my note:

I think there is indeed implied metadata about the chapter.  First of all, 
it looks like I've inferred it was indeed a chapter.  More to the point, I 
inferred (however unreliably) that it might be one of a collection of 
chapters, all in the same book.  I further guessed that it might have a 

Seeing either URI on the side of a bus, one might (unreliably) infer not 
only that can be contacted for authoritative representations 
of the resources separately (which the RFCs directly support), but also 
(unreliably) that there may be a containing resource which is the book as 
a whole, and that may have some real world ownership or 
control of it (I.e. they might employ the author as well as serving the 
Web resources).  All of that seems to be inferred metadata about chapter2. 
 If the URI were something more opaque, such as a uuid:xxxxxx, there is no 
way I could have inferred such things.  Why is it inappropriate to 
consider such information as metadata and to talk about it in the finding? 
Insofar as the inferred information proves true, it is definitely metadata 
about the chapter I think.

I do think we want to preserve and emphasize lots of the existing warnings 
about the downsides of either inferring or relying on metadata from the 
URI when you don't need to.  On the other hand, on the recent TAG call, 
there was considerable sentiment that people do the above chapter-ish 
munging all the time, and that it's a significant aspect of what makes the 
Web useful. 

I believe I've been tasked with drafting a finding that tells both sides 
of the story.  We'll see if I can do it without the result being too long 
or confusing.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Tuesday, 4 April 2006 20:51:02 UTC