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

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

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

but that's still "construct a super-set of the right result" while the
world is open :)

The query demonstrates one more headache, common for SQL and SPARQL --
there's no way to enumerate Monday, Tuesday ... Sunday right in the
query, there's a need in an external enumeration.

Best Regards,

Ivan Mikhailov,
OpenLink Software.

On Mon, 2008-05-19 at 23:17 +0200, Bernard Vatant wrote:
> Hi all
> 
> We're currently fighting with knowledge extraction about opening/closing 
> days for tourism facilities (hotels, restaurants, museums, campings ...).
> Information can be found in terms of closing and/or opening days during 
> a period, such as :
> "Widget Museum is open in 2008, from March 1st to October 31st, closed 
> on Sunday and Tuesday".
> NLP can extract the following description (1)
> 
> :WidgetMuseum   :openingPeriod   _:p1
> _:p1      :begins     2008-03-01
> _:p1      :ends        2008-10-31
> _:p1      :closingDay      :Tuesday
> _:p1      :closingDay      :Sunday
> 
> In an open world, we have no way to know if this is a complete 
> description, and can't infer that Widget Museum is open on Monday.
> 
> The other way round, if the information is given in terms of opening days,
> "Widget Museum is open in 2008, from March 1st to October 31st, on 
> Monday, Wednesday, Thursday, Friday and Saturday".
> Which yields the description (2)
> 
> :WidgetMuseum   :openingPeriod   _:p2
> _:p2      :begins     2008-03-01
> _:p2      :ends        2008-10-31
> _:p2      :openingDay      :Monday
> _:p2      :openingDay      :Wednesday
> _:p2      :openingDay      :Thursday
> _:p2      :openingDay      :Friday
> _:p2      :openingDay      :Saturday
> 
> ... we can't infer that Widget Museum is closed on Tuesday and Sunday. 
> IOW there is no way to identify logically _:p1 and _:p2 in an open world.
> 
> Supposing (1) is the standard target description required by the 
> ontology used in the system, I thought possible to write, in our closed 
> world, a SPARQL CONSTRUCT query which would yield (1) from (2).
> But thinking twice, my hunch is now that it is impossible, because of 
> the implicit open world assumption made by SPARQL.
> 
> Has someone already dealt with such issues? Any pointer welcome.
> 
> Thanks for your help
> 
> Bernard
>

Received on Tuesday, 20 May 2008 11:33:00 UTC