W3C home > Mailing lists > Public > semantic-web@w3.org > May 2008

Re: Open world issue (opening vs closing days) and SPARQL CONSTRUCT

From: Peter Ansell <ansell.peter@gmail.com>
Date: Wed, 21 May 2008 13:49:44 +1000
Message-ID: <a1be7e0e0805202049r650a3bdbu25272bc672981c8e@mail.gmail.com>
To: "Bernard Vatant" <bernard.vatant@mondeca.com>
Cc: "Ivan Mikhailov" <imikhailov@openlinksw.com>, "Semantic Web" <semantic-web@w3.org>, "Florence Amardeilh" <florence.amardeilh@mondeca.com>, Steph <steph.weiser@gmail.com>, "Philippe Laublet" <Philippe.Laublet@paris4.sorbonne.fr>

2008/5/21 Bernard Vatant <bernard.vatant@mondeca.com>:
>
> Hi Ivan
>
>> Bernard,
>>
>> My personal way of thinking about logic in open world is to treat a fact
>> _:p1 :closingDay :Tuesday as an conjunction of two: "Tuesday is a
>> closing day for _:p1" and "I know that Tuesday is a closing day for
>> _:p1". so the negation of that fact is "Tuesday is not a closing day for
>> _:p1 or I don't know that Tuesday is a closing day for _:p1".
>>
>
> In the "pragmatic open world", I would assume the former holds until/unless
> the information source cries otherwise, or clients provide angry feedback
> because they found the doors closed on Tuesday.
>>
>> Similarly, aggregates are a problem. "Select exact count of X" of SQL is
>> much more useful than "Select a count of known instances of X so it
>> might be used as a guess of actual count" in a open world.
>>
>> Sometimes the SPARQL world is closed, or partially closed. This is the
>> case when part of data come from closed sources such as relational
>> databases. When a SPARQL processor can access relational data directly,
>> such as OpenLink Virtuoso ( http://virtuoso.openlinksw.com ), the
>> negation becomes "more meaningful" as well as aggregates. That's why
>> Virtuoso extends SPARQL for business intelligence whereas W3C SPARQL
>> does not. W3C Data Access Working Group did not extend SPARQL with
>> features that are not required in most of open world applications (or
>> required but unsafe for newbie) .
>>
>> The conclusion. Yes, your case can be handled by something like
>>
>> CONSTRUCT { ?s :openingDay ?dayofweek }
>> WHERE
>>  {
>>    :WidgetMuseum   :openingPeriod ?s
>>    ?s :begins 2008-03-01 .
>>    ?s :ends        2008-10-31 .
>>    ?dayofwee a somedictionary:dayOfWeek .
>>    OPTIONAL { ?s2 :closingDay ?dayofweek . FILTER (?s2 = ?s) }
>>    FILTER (!bound (?s2))
>>  }
>>
>
> Found something of the like in paper quoted by Stefen, and even in the
> SPARQL specification itself, under the title "negation by failure".
> Not sure I've completely understood yet how it can work, in particular the
> semantics of ?s2
> Any further explanation welcome ...

I wasn't quite sure how this would work until I checked out the
examples for the bound operator in the SPARQL specification.

Bound essentially returns true, and includes the current row in an
output set if the bound function returns true because its argument has
a Resource bound to it as part of the rest of the query. This makes
the !bound return true overall if a closingDay statement matching this
subject was *not* found in the optional section. The s2 = s is
necessary as far as I can tell in order to make sure the optional part
is properly separated from the rest, in order to test the existence of
the s2 closingDay ?dayOfWeek statement in the dataset that sparql is
running over. If the OPTIONAL fails then s2 is not bound to anything
and that row is included in the results, due to the !bound being true
if the OPTIONAL part failed.

It is still open world in my view due to the !bound being a negation,
where positive results are the only way of being sure that there was
actually "something" to match on. But if you have what you know to be
a complete data set it should work like a typical SQL query.

Peter
Received on Wednesday, 21 May 2008 03:50:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:22 GMT