W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: finite approximation of the minimal Herbrand model for a RIF Core/BLD ruleset.

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 24 Feb 2010 12:14:59 +0000
Cc: "Sandro Hawke" <sandro@w3.org>, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
Message-Id: <B4D032DA-E72E-4FA5-AC7F-27B7C00ECEA0@deri.org>
To: Jos de Bruijn <debruijn@inf.unibz.it>

On 24 Feb 2010, at 11:59, Jos de Bruijn wrote:

> 
> 
> On 2010-02-24 12:53, Axel Polleres wrote:
> > Note in that context that, another issue is the following:
> >
> > RIF entailment is strictly speaking not only parametric to the
> > dialect (Core/BLD/strongly safe core ... I hope we can define a
> > unified entailmanet regime which catches all three) but also to the
> 
> The definition of entailment is the same for all three, so I don't see
> why one would define different entailment regimes in the first place?

Sorry, clarification: the question is whether canonical finite approximations 
for RIF strongly-safe Core/Core/BLD are uniformly defined for all three or differently... example:

The following is in strongly safe core:

p(1)
q(X+1) :- p(X). 
r(X+1) :- q(X). 

since this ruleset is stronly safe RIF Core, the minimal herbrand model is finite, we could just take the least fixpoint of T_R for stronly safe RIF core to compute it, i.e. the finite extension of r would be {r(2)}.
However, if we take the finite approximation for general RIF Core and BLD via HU_1 as I had sketched it,
r(2) would not be in the consequences, as it is not computable from HU_1. 

Open issue from my side, whether we can find a definition that defines a finite approximation that combines both HU_1 and strongly safe "portions" of a rule set... but that would be neat...

best,
Axel

> Jos
> 
> > combination semantics chosen, cf.
> > http://www.w3.org/TR/rif-rdf-owl/#Profiles_of_Imports, i.e. do we
> > want to define only a RIF/Simple-Entailment regime, or also:
> >
> > RIF/RDF RIF/RDFS RIF/D RIF/OWL RIF/OWL DL RIF/OWL Full
> >
> > (btw, the latter two have been renamed in the latest editor's draft
> > in RIF, , cf.
> > http://www.w3.org/2005/rules/wiki/SWC#Profiles_of_Imports, due to
> > comments form the OWL WG to RIF/OWL Direct RIF/OWL RDF-Based )
> >
> > To start with, I think my original proposal works straightforwardly
> > for RIF/Simple, the others (particularly when we jump up to OWL) need
> > more thought, and probably checking back with Jos & Birte ;-)
> >
> >
> > Axel
> >
> >
> > P.S.: <chairhat-off>I note that for my main use case, which is
> > modeling different rule based approximations of fragments of the RDFS
> > and OWL semantics in RIF, RIF/Simple is probably
> > sufficient..</chairhat-off>
> >
> >
> > On 24 Feb 2010, at 11:38, Jos de Bruijn wrote:
> >
> >>
> >>>> On 2010-02-24 12:24, Axel Polleres wrote:
> >>>>> Below I forward some thought from jos on this with his
> >>>>> consent:
> >>>>>
> >>>>> @jos: can you ealborate what exactly you mean here:
> >>>>>
> >>>>>> 2- the RDF(S) semantics gives you more than just blank
> >>>>>> nodes.
> >>>>>
> >>>>> in how far is this a (potential) problem?
> >>>>
> >>>> I'm not saying this is a problem per se. You were simply not
> >>>> taking the RDF(S) semantics (i.e., axiomatic triples &
> >>>> semantics conditions) into account in the definition you
> >>>> proposed.
> >>>
> >>> yes, this is another issue. good point.
> >>>
> >>>> Of course one needs to be careful with the infinite axiomatic
> >>>> triples, especially when considering query answering and not
> >>>> just checking entailment.
> >>>
> >>> A common way to deal with this in a finite approximation way is
> >>> a) ignoring (specifically the infinite) axiomatic triples
> >>> alltogether b) take only those from the infinite axiomatic
> >>> triples (those about container membership properties) that appear
> >>> in the graph... I believe the latter is what we do in the current
> >>> RDF(S) entailment regime, yes Birte?
> >>
> >> b) seems to be the most reasonable way to go; but make sure to
> >> include at least one representative (for queries with blank
> >> nodes). Unnecessarily ignoring parts of the semantics (as in a)
> >> seems rather a bad idea.
> >>
> >>
> >> Cheers, Jos
> >>
> >>>
> >>> Axel
> >>>
> >>>>
> >>>>
> >>>> Jos
> >>>>
> >>>>>
> >>>>> Axel
> >>>>>
> >>>>>
> >>>>>> ============================================================================
> >>>>>>
> >>>>>>
> On 2010-02-24 12:07, Axel Polleres wrote:
> >>>>>>>
> >>>>>>> On 24 Feb 2010, at 11:04, Jos de Bruijn wrote:
> >>>>>>>> On 2010-02-24 11:28, Axel Polleres wrote:
> >>>>>>>>> Hi Jos,
> >>>>>>>>>
> >>>>>>>>> Can you check this briefly and tell me whether I
> >>>>>>>>> don't oversimplify things here?
> >>>>>>>>
> >>>>>>>> I will have a more detailed look at it later on, but a
> >>>>>>>> few first comments: - you do not consider equality
> >>>>>>>> between data values, e.g. "1"^^int="1"^^decimal
> >>>>>>>
> >>>>>>> hmmm, I am at the moment, not sure how far this is a
> >>>>>>> problem, but I definitly should include this in the
> >>>>>>> issues!
> >>>>>>>
> >>>>>>>
> >>>>>>>> - I did not see how a minimal model for RIF-RDF
> >>>>>>>> combinations is defined, in particular I see no blank
> >>>>>>>> nodes or RDF(S) semantics
> >>>>>>>
> >>>>>>> ? Can't we just treat them as skolem constants? We are
> >>>>>>> just interested in query answering...
> >>>>>>
> >>>>>> 1- if you treat blank nodes as skolem constants you need to
> >>>>>> say so. 2- the RDF(S) semantics gives you more than just
> >>>>>> blank nodes.
> >>>>>>
> >>>>>>> if you agree, I forward your comments to SPARQL, ok?
> >>>>>>
> >>>>>> Sure.
> >>>>>>
> >>>>>>
> >>>>>> Jos
> >>>>>
> >>>>>
> >>>>
> >>>> -- Jos de Bruijn Web:   http://www.debruijn.net/ Phone: +39
> >>>> 0471 016224 Fax:   +39 0471 016009
> >>>>
> >>>
> >>
> >> -- Jos de Bruijn Web:   http://www.debruijn.net/ Phone: +39 0471
> >> 016224 Fax:   +39 0471 016009
> >>
> >
> 
> --
> Jos de Bruijn
>   Web:   http://www.debruijn.net/
>   Phone: +39 0471 016224
>   Fax:   +39 0471 016009
> 
Received on Wednesday, 24 February 2010 12:15:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT