- From: Williams, Stuart \(HP Labs, Bristol\) <skw@hp.com>
- Date: Fri, 21 Jul 2006 10:15:49 +0100
- To: <noah_mendelsohn@us.ibm.com>
- Cc: <www-tag@w3.org>
[At Noah's request, this is a revised re-post, on-list, of some comments that I made to Noah off-list] Hello Noah, I've taken a pass over the latest draft and used MS Word to annotate comments into a copy. I've posted the resulting 'html' and a PDF versions to www-archive@w3.org [1][2].[Aside: I have yet to find good alternative for annotating comments into an HTML document so that they can be read in context.] Anyway... take the embedded comments for what they are worth. There are certainly no changes that I would insist that you make. I think that the only thing that I found a little jarring in places was an almost implicit presumption that say words like Chicago or Boston embedded in a URI are metadata. I found myself not wanting to allow them to be metadata, and I think that the only circumstances where I think I'd be willing to conceded that they were metadata is where the assignment authority had structured their URIs for the express purpose of being able to parse them and extract metadata from them. If someone happens to presume some sgement of a URI to be metadata without that being the express purpose of the URI authority... then in general... I don't think that it is. That probably not a very good or sound distinction... but I think that the intent of the URI authority/publisher is important. Keep up the good work. Many thanks and best regards, Stuart -- [1] http://lists.w3.org/Archives/Public/www-archive/2006Jul/att-0009/metaDat aInURI-31-skw-ann.pdf [2] http://lists.w3.org/Archives/Public/www-archive/2006Jul/att-0009/metaDat aInURI-31-skw-ann.htm > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] > On Behalf Of noah_mendelsohn@us.ibm.com > Sent: 09 June 2006 23:37 > To: www-tag@w3.org > Subject: [metadataInURI-31] New draft of "Use of Metadata in > URIs" for consideration at F2F > > > 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: > > 1. The MUST NOT constraint now only refers to software > 2. 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 > -------------------------------------- > > > > >
Received on Friday, 21 July 2006 09:16:02 UTC