- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Mon, 11 Feb 2008 10:11:11 +0000
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
- CC: "public-awwsw@w3.org" <public-awwsw@w3.org>
Hello David, > -----Original Message----- > From: Booth, David (HP Software - Boston) > Sent: 10 February 2008 09:00 > To: Williams, Stuart (HP Labs, Bristol) > Cc: public-awwsw@w3.org > Subject: HTTP inference rules [was: AWWSW minutes from today] > > > From: Williams, Stuart (HP Labs, Bristol) [ . . . ] > > > From: David Booth > > [ . . . ] > > > Thanks for your comments on > > >>> http://esw.w3.org/topic/AwwswDboothsRules > > [ . . . ] > > > Yes, I was trying to say that the app knows to use the > > > follow-your-nose principle, but I guess I should have worded it > > > better. I've hopefully improved the wording now. Check the wiki > > > again and see what you think: > > > http://esw.w3.org/topic/AwwswDboothsRules > > > > > The page still speaks of assumptions... I was trying to say that what > > you are speaking of is not an assumption, I believe that its is more > > axiomatic in the architecture of the web. > > Which assumptions do you mean? Can you be specific? # And we'll assume that the app knows to "follow its nose" to # learn more about <...#dan> by dereferencing the racine # of its associated URI... Ok... I guess it depends on where the weight of assume falls... I was reading it as a stated assumption that to (roughly) dereference(access) <racine#fragment> that you have to (try-to) deference(access) <racine>... I can see other ways of reading this: ie. the assumption is not about the mechanics of dereference(access), but about the app knowing or having a strategy for, given a URI, how to retrieve either a representation or a description (with little control over which at the outset - as things stand). Anyway I suspect that we'd done that one to death. <snip/> > > [ . . . ] > > >> # And we'll assume that in parsing the above triple, the app > > >> *also* automatically asserted the following triple: > > >> # <http://dbooth.org/2008/httpinf/moon.rdf#themoon> log:uri # > > >> "http://dbooth.org/2008/httpinf/moon.rdf#themoon"^^xsd:anyURI . > > >> > > >> This is an obvious tautology... and as such harmless... > > >> > > > > > > I don't think it is a tautology. AFAICT this is a > > > necessary assumption, since in the RDF semantics, > > > <http://dbooth.org/2008/httpinf/moon.rdf#themoon> denotes a > > > resource. > > The URI is at the syntactic level, not semantic. > > How would any rules otherwise know what URI had been used to denote > > that resource? > > > > > "The thing denoted by the URI 'xxx' is denoted by the URI 'xxx'." > > > > Looks like a straight tautalogy to me. > > It sounds like you are confusing syntactic and semantic > domains. I don't think so. > Semantically > <http://dbooth.org/2008/httpinf/moon.rdf#themoon> denotes a > particular resource, and nothing more. That exact same > resource could just as well be denoted by some other URI, > such as http://example/fribjam , in which case the above > could have been written as: > > <http://example/fribjam> log:uri > "http://dbooth.org/2008/httpinf/moon.rdf#themoon"^^xsd:anyURI . > > which no longer looks like a tautology even though it would > have the *exact* same semantics. Ok... yes, that's not a tautology, but it is different from the original statement. It's probably closer to the blank node form which i mentioned in an earlier response. [] log:uri "http://dbooth.org/2008/httpinf/moon.rdf#themoon"^^xsd:anyURI . Anyway, we've probably killed this one enough as well. > > [ . . . ] > > >> 2) I think this will quickly get messy with some means to > > >> distinguish inferences derived from different responses. > > >> Over time > > >> the multipicity of different responses and monotonic assertions > > >> inferred from them may lead to inconsistent KBs. > > >> > > > > > > Correct. It does not prevent a URI owner from issuing conflicting > > > URI declarations at different points in time, thus causing a "URI > > > collision": > > > http://www.w3.org/TR/webarch/#URI-collision > > > The architecture does not prevent URI collisions, but > > > admonishes URI owners and users to avoid them. If an owner > > > issues conflicting URI declarations, users are likely to avoid using > > > the URI. > > > > > I'm not talking about URI-collision - I taking about a KB which has > > become inconsistent... where it is possible to prove that there are no > > intepretations which satsify the model. > > [ . . . . ] > > Aren't you talking about different URI declarations being > served at different times, thus causing inconsistencies over > time? I'm not so much focussed on URI declarations as a general observation that accumulating knowledge over time, without isolating temporal context, may, over time, lead to a KB that becomes inconsistent and unusable. :theTrafficLight :isAt :green . :theTrafficLight :isAt :red . > If so, then the URI is being declared differently at > different times, i.e., the same URI is used to denote > different things at different times, which is one form of URI > collision. (I.e., the same party is using the URI to denote > different things at different times, rather than different > parties using the URI to denote different things.) If that > isn't what you are talking about then please explain. I don't quite know how to square that with an earlier response which seemed to take a relaxed stance about can be 'in' a URI declaration. <quote> > > > > Major problems: > > > > 1) I don't see that the conclusion necessarily follows from the > > premises. It *only* follows of ?formula says something 'declarative' > > (your word) about (the referent of) ?u. > > Otherwise it could be saying things about a whole bunch of things and > > may say nothing at all about (the referent of) ?u. > > Correct. That would be a poor quality URI declaration, and users may thus choose to avoid using that URI, but being poor quality does not prevent it from nonetheless being a URI declaration. </quote> > David Booth, Ph.D. > HP Software > +1 617 629 8881 office | dbooth@hp.com > http://www.hp.com/go/software > > Opinions expressed herein are those of the author and do not > represent the official views of HP unless explicitly stated otherwise. > Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Monday, 11 February 2008 10:13:55 UTC