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