W3C home > Mailing lists > Public > www-tag@w3.org > November 2006

RE: Dates in URIs?

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 10 Nov 2006 17:37:29 -0500
To: "Mike Schinkel" <mikeschinkel@gmail.com>
Cc: www-tag@w3.org
Message-ID: <OFEF11DFF4.2A81D514-ON85257222.0077FA56-85257222.007C4D36@lotus.com>
Mike Schinkel writes:

> TAG may has established what is correct and what is not correct about 
meta
> data in URIs, but I personally think that finding is a bit unrealistic.
> Yes, if you are dealing with professional developers and IT folk, but 
not
> with the general public.  Even though technical professionals really 
want
> the URLs to be opaque, real world people are creating URLs and real 
world
> people are seeing and using URLs every day. The more they come in 
contact
> with URL the more they will believe that URLs have meaning and the more 
they
> come to rely on that meaning.

I don't think that's at all a fair paraphrase of the finding as drafted. 
Among the many parts of the finding that seem at odds with the above 
characterization is the following quote from the conclusions:

"The ability to explore and experiment is important to Web users. Users 
therefore benefit from the ability to infer either the nature of the named 
resource, or the likely URI of other resources, from inspection of a URI. 
Such inferences are reliable only when supported by normative 
specifications or by documentation from the assignment authorities. In 
other cases, users should be aware that their inferences may be incorrect 
and the effect could be malicious."

That seems more or less the opposite of what you're claiming the finding 
says.

In a later note, Mike wrote:

> However, whereas I didn't see anything "wrong" in the finding it,

OK, good. That wasn't clear from what you wrote above.

> it was the omissions that concerned me.  And I don't necessarily 
> think these omissions would need be addressed in metaDataInURI-31 
> but I do think it would be good if a future issue could address them. 
> 
> The ommissions that concerned me were guidance about how best to use
> metadata in a URI if metadata is going to be used.  And I don't mean
> "well known names" but instead things like "If you are going to 
> include a year in a Url, you should considering the following: etc. 
> etc."  Which is a good segue to what you and I were going to discuss
> offline...?

Well, I think that the pertinent RFCs and this finding are striking the 
right balance in layering these concerns. 

I'm also not convinced that it would be helpful or appropriate to do 
another finding on, say, "the use of dates as metadata in URIs", which 
seems to be what you're suggesting.  Dates (and other metadata) tend to be 
used for very domain-specific purposes, and with rather domain-specific 
syntax and semantics.  I note that much of the work the TAG produces winds 
up with URI's that look like:

        http://www.w3.org/2001/tag/2006/10/24-agenda.html


which has segments relating to two different dates, I.e. in 2001 and 2006 
(The TAG's subset of URI space was assigned in 2001; the other dates often 
relate roughly, though not necessarily exactly, to the time at which 
editing on the resource in question began in CVS — that in turn is 
sometimes but not always the date a user would consider to be the date of 
publication).  The dated copy of the latest draft of the finding also 
encodes two dates, but with very different syntax:

        http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html


Presumably the latter date representation is chosen to include the month 
and day, but also to facilitate mappings to filenames that encode the date 
(I.e. so multiple drafts can be in the same filesystem directory).  I 
think these are the sorts of issues you'll get into if you try to 
standardize such things across the Web.  I don't think one size fits all, 
and I'm certainly unconvinced that if there were work to be done, the TAG 
would be the place to do it.  To the extent that certain communities wish 
to agree to use dates consistently in URIs, and to document that they are 
choosing to follow a common convention, that's fine.  I don't think those 
conventions should typically be documented in the RFCs for schemes like 
http, and I don't think they should be in findings such as this which are 
meant to apply to the broad range of resources that comprise the Web.

Overall, with the possible exception of the comments from Stuart Williams 
(I.e. on the degree to which http is a good example of a scheme that 
supports the encoding of particular metadata), which we've discussed 
before and on which I believe we've amicably agreed to disagree, I haven't 
seen anything in this thread that convinces me the finding should change.

It is true that some on this thread have expressed unhappiness with the 
W3C's URI assignment policies, and might have preferred if the dates 
encoded in such URIs had been related to the time of publication as 
opposed to the time of URI assignment.  The finding correctly points out 
that such 'friendly' assignment policies can be helpful to users, but it 
also makes clear that putting helpful metadata into URIs is optional.  So, 
I think the finding's not broken, and the W3C URI assignment policy is at 
worst unhelpful to certain users.  If that's the concern, it should be 
taken up with those who set the URI policy for the W3C. 

Noah

[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html#N1023D


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------



Received on Friday, 10 November 2006 22:37:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:43 GMT