- From: David Booth <david@dbooth.org>
- Date: Tue, 29 Mar 2011 08:24:03 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: AWWSW TF <public-awwsw@w3.org>
On Thu, 2011-03-24 at 15:57 -0400, Jonathan Rees wrote: > Agenda: continue review of http://www.w3.org/2001/tag/awwsw/issue57/latest/ . Here are some notes that I started collecting a few days ago, but did not finish. They pertained to the current version at that time, so they may not all still be relevant. The latest version looks significantly improved. It looks like you've been putting a lot of good work into it. 1. One of the biggest problems I see is that this document ignores previous work that I have done in this area that is clearly relevant, most notably the following: http://dbooth.org/2009/lifecycle/ Quoting from the abstract: [[ Various parties are typically involved in the creation and use of a URI, including the URI owner, an RDF statement author, and a consumer of that RDF statement. What principles should these parties follow, to ensure that a consistent resource identity is established and (to the extent possible) maintained throughout that URI's lifetime? This paper proposes a set of roles and responsibilities for establishing and determining a URI's resource identity through its lifecycle. ]] http://dbooth.org/2010/ambiguity/paper.html Quoting from the abstract: [[ This presentation sheds light on these issues by: . . . proposing a standard operational sequence for determining the intended referent of a URI, even in the the presence of semantic extensions. ]] 2. Section 1.3 "A dereferenceable URI refers to the information resource at that URI" is describing a rule (i.e., that a dereferenceable URI refers to the IR at that URI) that is currently in use by many, so it belongs in section 3 under "General definition methods in current use". 3. Regarding: [[ Variant use case: Same as above, but Bob's bibliography includes a number of RDF documents, and his metadata includes information relevant for making use of those RDF documents. ]] Do you mean, for example, that IR('http://example/spoonwing') is an RDF document? If so, why is this important to mention as a variation of the original use case? 4. Regarding: [[ Variant use case: Same as above, but instead of being a person, Bob is a tool that is charged with updating all the documents on a Web site with license metadata. ]] Can you be more specific about the issue that you are trying to bring out? Is it the fact that an automated tool is doing it rather than a human? Or is there some special issue that license metadata raises? 5. Sec 2.1: This use case seems to be intended to raise the following questions: a. What phrase should Bob use to refer to the report? b. How should Carol know to dereference http://example/spoonwing ? c. How should Carol know that Bob's phrase is intended to refer to IR('http://example/spoonwing')? I think it would be helpful to state these questions explicitly. 6. Sec 2.2: This use case seems to be intended to raise the following questions: a. What phrase should Alice mint, to refer to Fred (the mynah)? b. Where/how should Alice publish the definition of her phrase? c. How should Carol know how to find Alice's definition? d. How should Carol know to interpret Alice's definition as a definition of Alice's phrase (as opposed to, say, a movie review)? 7. It would be helpful to uniquely number each use case variant, so that we can refer to them more easily. 8. Sec 2.2: The variations of this use case sound very similar to use case 2.1, where Bob's bibliography is in a web page and Alice's report is either accessible or not. 9. Are the characters (Alice, Bob, Carol) supposed to be the same people across use cases? If so, this could be clearer if the use cases were more coordinated. For example, Bob's bibliography in use case 2.1 could be published at http://example/biblio, and that could the same "Bob's document" that use case 2.2 mentions. If not, it would be clearer to use distinct names. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Tuesday, 29 March 2011 12:24:36 UTC