Re: AWWSW minutes from today

Hello David,


Booth, David (HP Software - Boston) wrote:
> Hi Stuart,
>
> Thanks for your comments on
>   
>>> http://esw.w3.org/topic/AwwswDboothsRules
>>>       
> Responses below.
>
>   
>> From: Williams, Stuart (HP Labs, Bristol)
>>
>> Hello David,
>>
>> Some comments on your rules wiki page:
>>
>> In "Sample Input Data":
>> -----------------------
>>
>>       # HTTP ontology mentioned by Jonathan:
>>       @prefix http: <http://www.w3.org/2007/ont/http#>
>>
>> The given URI doesn't appear to resolve to anything :-(
>>     
>
> In my browser it displays as a blank page, though if you "View source" you will see that it is RDF.
>   

/me blushes :-)
>   
>> There are a number of obvious prefixes that need 'grounding'
>> and have 'example' in the authority field.
>>     
>
> Yup.  Not done yet.  :)
>
>   
>> # And we'll assume that the app knows to dereference the racine
>> # in search of a URI declaration, and we'll assume that
>> # the racine dereferences (perhaps indirectly via 301, 302 or 307
>> # redirects) to a 200 OK response with an application/rdf+xml
>> # body.  The following RDF expresses these assumptions.
>> # Incidentally, the first line is needed to get around RDF's silly
>> # restriction that a literal cannot be a subject in a triple.
>>
>> The intrinsic action of HTTP (and if I understand TimBL
>> correctly - ALL (architecture conformant) Web access
>> protocols) uses the 'racine' on the request line. ie. it is
>> an *intentional* facit of the architecture that any fragment
>> part of the URI is *not* included in a web retrieval
>> request... ie. this is *not* an assumption that has to be
>> made, it is intrinsic behaviour of ALL (architecture
>> conformant) web access protocols.
>>     
>
> 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.

>   
>> BTW: I put 'racine' in quotes above because you are using it
>> as a relation between strings and 'log:racine' from which I
>> think your use derives is a relation between resources.
>>     
>
> Correct.
>
>   
>> I don't know why you have made explicit mention of 301, 302
>> or 307 and made absolutely no mention of 303 which is what
>> the TAG has been encouraging the use of.
>>     
>
> The 303 rule is separate, a little farther down the page.
>   
I was speaking of the comment line in the sample input... any way you've 
eliminate that mention of 301, 302 and 307, so 303 is no longer 
noticeable absent,

>   
>> [aside: And... while we're on the topic... (not that you have
>> said otherwise) it is not in the gift of URI scheme
>> specifications to constrain in any way the use of frag ids
>> with the scheme in question, or to endow them with semantics.]
>>
>>       http:hasDirectGetReply...
>>
>> is going to be problematic... in that there are many of them
>> over time. Maybe time needs to be used as a descriminant here
>> - question is whether that should be intrinsic to the reply
>> or 'extrinic' to the model. My guess is that a Reply is a
>> subclass of Message which itself is a subclass of Event (all
>> in some ontology) and that the temporal aspects should be
>> recorded/inheritited from Event (which may have duration).
>>     
>
> So far the rules have not needed time, but it certainly may be desirable for other reasons to record the time of the reply, or perhaps to make use of the etag, for example to distinguish one reply from another.
>
>   
>> In Rules
>> --------
>>
>> # 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 also happens to entail a blank node:
>>
>>       _:b1 log:uri log:uri
>> "http://dbooth.org/2008/httpinf/moon.rdf#themoon"^^xsd:anyURI .
>>
>> ie. a blank node (actually an infinite number of them... I'm
>> told) - which for reason I find more interesting... not sure
>> why... just musing that's all.
>>     
>
> I don't follow what you mean, unless you are just saying that any node implies an infinite number of blank nodes (because they could all really be the same resource), but perhaps I don't need to.
>   
Yes...
            [] log:uri 
"http://dbooth.org/2008/httpinf/moon.rdf#themoon"^^xsd:anyURI .

follows from their being a resource that has that URI.

>> # hasDeclaration rule for 200 response with RDF.
>> {       ?uri a xsd:anyURI ;
>>                 uri:hasRacine ?racine .
>>         ?racine http:hasGetReply ?reply .
>>         ?reply http:hasStatusCode "200" .
>>         ?reply http:hasContentType "application/rdf+xml" .
>>         ?reply http:hasEntityBody ?body .
>>         ?body rdfx:parsesTo ?formula .
>> } =>    {
>>         ?racine urid:declares ?u .
>>         } .
>>
>> Minor problems... ?uri and I presume ?racine are bound to URI
>> bearing strings of type xsd:anyURI. Cwm may be different, but
>> for RDF these cannot be the subject of triples (some regard
>> this a bug in RDF - I remain to be convinced). This leads to
>> confusion about the subject of many of these statements.
>>     
>
> I thought I was able to get around that restriction by saying things like:
>
>  _:danuri owl:sameAs "http://example/prople#dan"^^xsd:anyURI .
>
> and then using _:danuri as the subject of the triples.  Am I wrong?  CWM didn't seem to complain about it.
>
>   
>> 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.
>   
Hmmmm.....
 
>> 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.

>> # hasDeclaration rule for RDF via 303 redirect.
>> {       ?uri a xsd:anyURI ;
>>                 uri:hasRacine ?racine .
>>         ?racine http:has303Reply ?reply .
>>         ?reply http:hasStatusCode "200" .
>>         ?reply http:hasContentType "application/rdf+xml" .
>>         ?reply http:hasEntityBody ?body .
>>         ?body rdfx:parsesTo ?formula .
>> } =>    {
>>         ?racine urid:declares ?u .
>>         } .
>>
>>
>> Similar problems to the previous rule.
>>
>>
>> # 301 case. 302 and 307 are the same.
>> {       ?u1 http:hasGetReply ?reply1 .          # IF ?u1
>> derefs to ?reply1
>>         ?reply1 http:hasStatusCode "301" .      # ... with 301 status
>>         ?reply1 http:hasLocation ?u2 .          # ... and URI ?u2
>>         ?u2 http:hasGetReply ?reply2 .          # ... which
>> derefs to ?reply2
>> } => {                                          # THEN
>>         ?u1 http:hasGetReply ?reply2 .          # ... ?u1
>> derefs to ?reply2
>> } .
>>
>> Not sure I agree with this though this is probably me being
>> 'picky' (again). I think the conclusions are or should be
>> that ?u1 has moved (on a temporary or permanent basis) to
>> ?u2. Maybe those are additional conclusions. *iff* ?u1 and
>> ?u2 are the same resource (maybe an owl:sameAs or
>> owl:sameIndividual is appropriate too... but I'd be a bit
>> guarded (again) about the temporal aspects) then I suppose
>> that the conclusion you reach is 'ok' but I am uneasy.
>>     
>
> I think the conclusions that you suggest might be good candidates for additional conclusions.  This might be a good topic for discussion.  I didn't need them, because I was primarily using hasGetReply to get to a hasDeclaration inference.
>
>
>
> 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.
>
>   
Regards,

Stuart
--

Received on Friday, 8 February 2008 00:46:55 UTC