Comments on SputnikDraft Note on Minting, Defining, and Using URIs

Please add your comments below, one section per commentator.

Comments by David Booth 8-Oct-2007

Thanks for doing this. Here are my suggestions.

General comments:

1. I think it would help to dramatically shorten this and make the advice much more specific and prescriptive -- almost cookbook style. At present it feels like it is getting bogged down in hypotheticals. Perhaps it could use some editorial brainstorming around a table, to clarify the message?

I agree that short is good. However, the document is likely to give advice in direct contradiction to that coming from the TAG and other influential parties, so I think the underlying philosophy and assumptions have to be stated so that the argument can be made on principle. Perhaps there should be a separate HCLS note giving rationale for the advice? -JAR

2. Use existing WebArch (and other) terminology if possible. I don't think there is a big need to define your own terms in this document.

Can you be more specific? I've put my reasons for "term" vs. "URI" in the draft; "representation" is undefined (and I don't think I need it for this document); "resource" is undefined and is used in conflict with the English word of the same spelling; "information resource" is for all practical purposes undefined but I use it anyhow, with scare quotes. My "web resource" (maybe "web-based information resource") is an "information resource" that is on the web, e.g. the one named by http://news.google.com/, but it is a proper subclass of "information resource" because the IR named by data:text/plain,penguin is not a web [information] resource. I do need a term for this idea. I suppose I could work "access" and others into the presentation. But overall I want this to be a report that an ordinary person can read, not just standards geeks. -JAR

3. Perhaps break the recommendations down into advice on minting URIs (as producers) versus advice on using URIs (as consumers).

Most of the advice is on producing (minting, defining, choosing, using). Only one section is on consuming (understanding). The section order comes from my "threats" analysis, but I will see if there's a way I can make the organization more useful.

Some specific (mostly editorial) comments:

4. Re: "Current practice and guidelines such as W3C recommendations will influence meaning, making interpretation a political and cultural process, just as it is with natural language." We don't know how this will play out. This sounds unnecessarily pessimistic. How about the following instead: "W3C Recommendations and other guidelines will be used to determine the interpretation of a graph, but social and political processes may also influence interpretation, just as just as for natural language."

Good. I've used your text with only small change.

5. "definitions of terms are true by fiat, and cannot be true or false" -- please explain what you mean.

I've clarified in the draft, I think. (You're right, the "cannot be true" part was ridiculous.) Let me know if it's still unclear.

6. Not sure this is needed: [[ The most essential characteristic of scientific endeavor is skepticism. This does not mean that we restrict ourselves to uttering only well-established truths. Instead, skepticism is reflected in careful attention to the logical and bibliographic support for assertions. The chain of support helps an agent processing some information to form its own judgments of the validity and usefulness of the information for the application at hand. Inference and citation are therefore at the heart of any use of natural or formal language in science. ]]

Maybe not. I'll see if anyone likes the paragraph. I put it there for a reason; it's an implicit call for ontological rigor (relative to much of what's being advocated by some parties). I know I'm not being clear about this, so I'll think about how to be more direct.

7. Re: "By convention advocated by AWWW, a web resource [JAR's coinage] is automatically named by its URI, and therefore does not need an explicit definition." I don't think this is correct. A definition can still be helpful to indicate more about that information resource. For example, it is useful to know that a URI serves the *current* weather in Oaxaca, rather than just the weather on 9-Oct-2007.

TimBL tells me that URIs for information resources on the web name whatever the server does, not what it should do. Therefore, statements relating such an IR to weather are only expressions of sincere intent, not true statements about the IR, which is subject to mistakes, server failures and hijacking, change of webmaster, and so on. Recognizing this problem is very important as this is the ontologically deepest claim laid against the http: scheme by advocates of LSIDs and the info: scheme, many of whom are colleagues we want to be able to communicate with.

8. I don't think this is needed: [[ The data: URI scheme, although quite limited, is also interesting in that it specifies a pure "information resource" without incurring the uncertainty around what the network or any web server does or will do. data: URIs may be taken to be terms denoting "information resources" having exactly one "representation", namely the one written in the URI itself. ]]

You are probably right. It goes to support the point above about the does/should distinction for web IRs.

9. This seems slightly garbled: [[ As a consumer of RDF, it is important to obtain the best definition. Ideally, there is only one definition, but one must defend against the instability and disagreement. ]]

This one and the following are fixed. Thanks a bunch! You're now an author. -JAR

10. s/author author/author/

11. s/as escribed above/as described above/