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 
> implicitly non-monotonic (at least for selects, possibly some
> order-dependant forms of optional with construct are monotonic since 
> not actually returning NULLs) so it seems reasonable to have to use 
> 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
>     (?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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:20 UTC