I have prepared a new draft of the metadata in URI finding [1,2] for
review at the TAG F2F next week. This draft attempts to deal with many
but not quite all of the significant comments received on the previous
draft [3]. The reason for publishing now is so that we have something
new to consider for next week, and in particular so that we can see
whether I have adequately addressed several of the high priority issues
that did come up.
The issues that I have attempted to address in this draft include:
Making clearer that the admonition against >software< dependencies on
unlicensed conclusions about metadata is very strong (MUST NOT), and
explaining why the rules for human users of the Web are somewhat
different. There are number of changes made to support this, including:
The MUST NOT constraint now only refers to software
Text added to the discussion says:
"Note that the constraint refers to conclusions drawn by software, which
must be trustworthy, as opposed to guesses made by people. As discussed in
"2.3 Guessing information from a URI", guessing is something that people
using the Web do quite often and for good reason. Software tends to be
long lived and widely distributed. Thus unlicensed metadata dependencies
in software result not only in buggy systems, but in inappropriate
expectations that authorities will constrain their URI assignment policies
and representation types to match the dependencies in the clients. For
both of these reasons, the constraint above requires that software must
not have such unlicensed dependencies."
There was a request to tighten the wording of the constraint in 2.1. I
have done that.
Section 2.4: I have included text from Frank Mannola (slightly edited)
explaining a bit better why conclusions can be drawn in the
"your-city-name-here" example. (Thank you, Frank!)
Section 2.4: Explained that HTML forms sourced from the same authoritity
as the URIs generated by the form carry more normative weight (as
documentation) than forms sourced from 3rd parties. This was noted by
several commentators.
The section that says "don't do it even when the specs say you could" is
now the second section (2.2) rather than the last, further emphasizing the
"software shouldn't peek" message.
Took out the word "thus" in the Intro, as requested by Raman.
TimBL and Raman: I'm particularly curious whether you are now comfortable
with the distinction made between software and people, as that was
important to both of you, and I think I've significantly strengthened that
message in this draft.
This is not intended as a final draft. If an issue already raised is not
covered, that may mean I propose not to address it, it may mean that I
hope to but haven't gotten to it, or that I haven't decided. I'll be
traveling a lot after the TAG meeting, but I will eventually distribute to
www-tag yet another draft covering additional issues, as well as an
explicit indication of issues that I propose not to address at all. I do
have comprehensive logs of everything I've seen mentioned since the last
draft; you don't need to restate comments already made, at least until
you see whether they are addressed later.
Thanks!
Noah
[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609.html
[3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060511.html
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------