W3C home > Mailing lists > Public > public-awwsw@w3.org > May 2010

Re: another draft

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>
Message-ID: <1274928165.16079.4086.camel@dbooth-laptop>
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
  . . .
  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

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

7. s/in my opinion/in part/

8. s/substituted for the carried in the response/carried in the

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

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
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"
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

18. I'm not sure where you're going with this paragraph or whether it is
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
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

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
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

 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC