- 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