- From: David Booth <david@dbooth.org>
- Date: Wed, 26 May 2010 22:42:45 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: AWWSW TF <public-awwsw@w3.org>
hi Jonathan, Again, thanks for your work on this. More comments: On Tue, 2010-05-25 at 21:21 -0400, Jonathan Rees wrote: > OK, if you're not fatigued, please read this over: > > http://www.w3.org/2001/tag/awwsw/web-semantics-20100525.html 1. Suggested rewording of some of the questions: [[ 1. http: URIs are currently used in the semantic web to name many kinds of things -- not merely web pages, but people, proteins, concepts, etc. When an http: URI that names a particular thing is used in an HTTP GET request, what should be the server's response, and how should the receive interpret the meaning of that response (e.g., as RDF assertions)? . . . 3. In the httpRange-14 decision the TAG suggested the use of 303 redirects in certain circumstances, but there are also other redirect codes in HTTP. What is "best practice" around the interaction between HTTP redirects and things that are named by redirected URIs? 4. When a URI is used as a name for something, there is a "binding" between the URI and that thing. How should such bindings be created, destroyed, communicated and/or discovered, and with what authority? ]] 2. I am not sure about question #2: [[ 2. Under what circumstances should an http: (or https:) URI be used to name something, in particular a metadata subject? ]] Some thoughts: - It was already answered by the httpRange-14 decision. - It is merely the flip side of question #1. - Why are you specially calling out metadata subjects? What is special about the subject of some metadata? Anything can be the subject of some RDF statements. What is so special about subjects that happen to have RDF statements written about them? Can you clarify your intent? 3. Add another question: [[ 5. The httpRange-14 decision indicated that an HTTP 200 response code means that a URI identifies an "information resource". However, there is confusion and disagreement about exactly what kinds of things should be considered "information resources", what kinds of things should be considered disjoint with "information resource", and hence whether HTTP 200 response codes should be used for a particular thing. Precisely what kinds of things should be considered "information resources", and what kinds of things should be considered disjoint from "information resources"? 4. s/We cannot recommend/We do not recommend/ 5. Please use "name" (or "denote") instead of "designate" throughout. It is simpler and clearer. 6. Change "location/designation best practice" to: "best practice in the use of URIs as names and/or locators, and the semantics of HTTP responses." 7. s/in my opinion/in part/ 8. s/substituted for the carried in the response/carried in the response/ 9. s/which I'll call/which we'll call/ 10. Regarding "containing R, where R is a RR". Perhaps it would helpful to use lower case letters for instance variables and upper case for classes/relations? E.g., earlier on you said "for all x, x is a Thing". In think it would make "containing r, where r is a RR" read a bit better. 11. s/Whether we choose to assume a W-statement/Whether we choose to believe a W-statement/ 12. Regarding "there exist T, T', R such that . . ." and "there exist T, R, R' such that . . . ", please use T1 and T2 or R1 and R2 throughout instead of T and T', as I think it will be clearer and it leaves quotes available for quoting. Actually, I guess these should be t1 and t2 or r1 and r2 if we use lower case for these, as suggested in #10. 13. Add after the "Note on time": [[ Note on requests Although W is also sensitive to the content of the HTTP GET request (see RFC 2616 section 12.1 http://www.ietf.org/rfc/rfc2616.txt ), we will also ignore requests for the moment. Later we'll redo the treatment to take requests into account. ]] 14. Regarding this: [[ A goal here is to render the ambiguity (between a thing and a description of a thing) referenced in the resolution as a contradiction within the axiomatic exposition. This goal has not yet been achieved. ]] Didn't both DanC and I already demonstrate this using n3 rules and an assumption that the class of "information resource" is taken to be disjoint from people? I can find the references if you need them. 15. s/Let WR be a proper subclass of Thing/Let WR be a subclass of Thing/ WR should *not* be specified as a *proper* subclass of Thing. Doing so is what leads to problems. 16. s/relectantly/reluctantly/ 17. Change: [[ David B's "it depends on how you interpret things" ]] to: [[ David B's "Ambiguity of resource identity is inescapable and we need to get used to it. This is merely one example. The architecture should not define the class of information resources as disjoint with anything." 18. I'm not sure where you're going with this paragraph or whether it is needed: [[ Assume that we don't need to worry about using choosing different URIs for different interlocutors; that is, for any thing, the same URI for that thing can be used with all interlocutors. This seems reasonable given the web architecture goal of global naming, although it is easy to see how it might go wrong. We could develop a theory without this assumption but it would be unnecessarily complex for this level of analysis. ]] Are you referring to the problem of multiple URIs for the same thing? Or are you referring to the problem of party A trying to figure out what URI party B used for something? 19. "Assume a relation hasURI(T,U) relating Things to URIs." Yes! Now we're on the right track. It is essential that we be able to talk about bindings of URIs to Things, because we will need to deal with the full URI lifecycle http://dbooth.org/2009/lifecycle/ 20. I don't understand this comment: [[ (This is a bit confused; we may need two relations, one for mapping URIs we get from others, and one for generating URIs to transmit to others. And choice of URI may depend on purpose: it makes sense to use a temporary redirect target for an HTTP request, but not for a SPARQL request. Operational details need working out.) ]] Why two relations? 21. Regarding this: [[ It ought to be useful for us to assume that hasURI is inverse functional, i.e. for any U there is at most one T with hasURI(T,U). ]] Well, you have to be careful about this. For a given graph it is functional. (BTW, we should probably stipulate up front that we're talking about the use of URIs in RDF graphs, because that's the context in which these issues arise. If we don't, then we need to talk about something like "context", and that's fuzzier, so I think we'd be better off restricting the discussion to RDF graphs.) But different graphs may use the same URI to denote different things, i.e., they may have disjoint interpretations, and this is okay -- it's a normal fact of life. It does *not* mean that anyone did anything wrong. And I definitely think it is going too far to say the following without some significant discussion of ambiguity and interpretations: [[ I.e. we (privately, within the theory we are building) "understand" any given URI as naming at most one thing (AWWW 2.2.1). ]] 22. This looks like an interesting idea: [[ To account for these, the hasURI relation needs to be time-indexed just as W is. ]] However, the harder part is not how to deal with time, but how to capture different graphs (or contexts), because the same URI can denote different things in different graphs. For example, in figure 3 of http://dbooth.org/2009/denotation/ imagine that one application added some assertions that limited the set of possible interpretations to the green and yellow apples, but another application added some different assertions that limited the set of possible interpretations to the red apple. We might be able to deal with this by adding another parameter for the graph: hasUri(x, u, t, g) meaning Thing x has URI u at time t in graph g. I don't know yet whether that will work out, but maybe it would. -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Received on Thursday, 27 May 2010 02:43:13 UTC