W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > February 2005

RE: Questions about OPTIONAL

From: <jos.deroo@agfa.com>
Date: Thu, 24 Feb 2005 16:52:47 +0100
To: geoff@sover.net
Cc: andy.seaborne@hp.com, public-rdf-dawg-comments@w3.org
Message-ID: <OF271C38BD.0A03C25C-ONC1256FB2.0053DAAC-C1256FB2.00573B24@agfa.com>

>> [...]
>> 
>>> 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 :)

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

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/
Received on Thursday, 24 February 2005 15:53:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:47 GMT