RE: Dates in URIs?

I think John explained it nicely:

"The W3C often assigns a year number as the most significant part of the
URI path 
so that it can be sure that URIs are unique over time, even as parts of
the URI 
                            ^^^^^^^^^^^^^^^^^^^^^^^^^
space are created and destroyed."

What on earth elevated these character sequences to the status of
"metadata" about anything?

Stuart
--

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Renato Iannella
> Sent: 09 November 2006 07:48
> To: noah_mendelsohn@us.ibm.com; John Cowan
> Cc: www-tag@w3.org
> Subject: Re: Dates in URIs?
> 
> 
> 
> 
> John wrote:
> 
> > It does not.  The W3C often assigns a year number as the most 
> > significant part of the URI path so that it can be sure 
> that URIs are 
> > unique over time, even as parts of the URI space are created and 
> > destroyed.
> > It is the TAG, not the particular resource, that dates to 2001.
> 
> Doesn't that make it even worse? - two bits of "metadata" 
> stuck in the same URI only one of which is about the resource.
> 
> Noah wrote:
> 
> > Exactly.  I'd like to point out that John's observation is 
> completely 
> > consistent with the draft finding [1], which I think does a pretty 
> > good job of making clear that the only metadata inferences you can 
> > depend on are ones for which the "encoding of such metadata 
> [I.e. in 
> > the URI] is documented by applicable standards and specifications".
> 
> I was not looking at Section 2.1 but Section 2.5.
> 
> Imagine I am Mary (don't try too hard) and instead of the 
> Bus, I see the report URL.
> What is "suggestive" to Mary (a non W3C person) about those 4 
> characters "2001"
> has something to do with years. The same that Chicago is 
> related to cities.
> 
> When I see this URL: <http://www.w3.org/TR/2006/WD-CSS21-20061106/>
> I get some good suggestions about its age.
> 
> 
> Cheers...  Renato Iannella
> National ICT Australia (NICTA)
> 
> 
> 
> --------------------------------------------------------------
> ------------
> This email and any attachments may be confidential. They may 
> contain legally privileged information or copyright material. 
> You should not read, copy, use or disclose them without 
> authorisation. If you are not an intended recipient, please 
> contact us at once by return email and then delete both 
> messages. We do not accept liability in connection with 
> computer virus, data corruption, delay, interruption, 
> unauthorised access or unauthorised amendment. This notice 
> should not be removed.
> 
>

Received on Thursday, 9 November 2006 11:54:43 UTC