RE: Questions about OPTIONAL

> -----Original Message-----
> From: jos.deroo@agfa.com [mailto:jos.deroo@agfa.com]
> Sent: Thursday, February 24, 2005 10:53 AM
> To: geoff@sover.net
> Cc: andy.seaborne@hp.com; public-rdf-dawg-comments@w3.org
> Subject: RE: Questions about OPTIONAL
> 
> >> [...]
> >>
> >>> That seems more like:
> >>>                A and (B or true)
> >>> than:
> >>>                A and (B or not B)
> >>>
> >>> You can't really simulate an optional without some form of not (NAF).
> >>
> >> I still do the former, but that gives, as Andy says unhelpful answers.
> >> I also did the latter a while back, but then in a monotonic way using
> >> log:notIncludes, however a test case like
> >
> > Do you mean non-monotonic? It seems to me an implementation of OPTIONAL
> is
> > implicitly non-monotonic (at least for selects, possibly some
> > order-dependant forms of optional with construct are monotonic since
> you're
> > not actually returning NULLs) so it seems reasonable to have to use
> nonmon
> > features in your language to implement it.
> 
> well Geoff, nonmon is exactly what I try to avoid in my implementation
> of RDF query inferencing e.g. by using such predicates as log:notIncludes
> which is described at http://www.w3.org/2000/10/swap/doc/Reach
> "Because a formula is a finite size, you can test for what it does not
> say"
> and that is pretty nifty :)

By my reading log:notIncludes is non-monotonic - it's just plain negation as
failure. The fact that it's used to implement defaults (at the page you
cited) is a clear indication of that.
 
> >> http://www.w3.org/2001/sw/DataAccess/tests/#dawg-opt-query-001
> >> is then not giving that "Eve" solution (it works nicely for instance
> >> when in the data :eve is used, but bnodes are existential variables
> >> and ?SRC log:notIncludes {_:eve_0 foaf:mbox <#mbox>} is not the case).
> >> I actually can't implement OPTIONAL
> >
> > That sounds like some sort of a quantification problem. In the query you
> > cite:
> >
> > PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> > SELECT ?name ?mbox
> > WHERE
> >     (?person foaf:name ?name)
> >   [ (?person foaf:mbox                 ?mbox) ]
> >
> >
> > if you've implement that as:
> >
> > (?person foaf:name ?name)
> >                and ((?person foaf:mbox ?mbox) or
> >                                not (?person foaf:mbox ?mbox))
> >
> > you're not saying: not exists any person with a foaf:mbox, but: not
> exists a
> > foaf:mbox for each person bound by previous triple.
> >
> > Or did I entirely misunderstand what you meant :-)?
> 
> it is implementation that is different :)
> ..have to reconstruct some past experience
> 
> above query is rewritten in N3 as
> 
> []
> q:select {<> q:answer (?name ?mbox)};
> q:where  {?person foaf:name ?name.
>           <dawg-data-01.n3> log:semantics ?F.
>           ?F log:notIncludes {?person foaf:mbox ?mbox}}.
> 
> []
> q:select {<> q:answer (?name ?mbox)};
> q:where  {?person foaf:name ?name; foaf:mbox ?mbox}.
> 
> 
> and for the attempt where
>   ?person foaf:name ?name.
> 
> is matched with
>   _:just_a_label foaf:name "Eve".
> 
> the triple
>   _:just_a_label foaf:mbox ?mbox

So if I understand correctly, log:notIncludes is treating the bnode like a
free variable (so in effect you're saying: not exists _any_ person with a
foaf:mbox since the existential ?person is converted to a universal by the
negation). That seems a little broken to me (or at least very awkward), but
even assuming it is the desired semantics for log:notIncludes I think you
could get the correct results by dragging in your other conditions to force
the proper quantification:

 q:select {<> q:answer (?name ?mbox)};
 q:where  {?person foaf:name ?name.
           <dawg-data-01.n3> log:semantics ?F.
           ?F log:notIncludes {?person foaf:name ?name; foaf:mbox ?mbox }.

(I'm assuming that's valid syntax or close to it)

Does that work?

 
> is a *simple entailment* from dawg-data-01.n3
> and hence is included (and we get no answer)
> which is of course just saying that we don't
> have negation :)
> 
> --
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Geoff

Received on Thursday, 24 February 2005 16:29:44 UTC