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

Whenever you filter out inferences/entailments some negative issues
will arise, but given that we have to guarantee finiteness we'll have
to make some compromise :-(

On 24 February 2010 13:23, Axel Polleres <axel.polleres@deri.org> wrote:
>> If you have a yes/no query:
>>
>> _:x rdf:type rdfs:ContainerMembershipProperty

Under the current definition you would get no/false over the empty
graph because _:x would have to map to a skolem constant and there is
none. The same happens if you put in a variable as in
ASK WHERE { ?X rdf:type rdfs:ContainerMembershipProperty}
over the empty graph the answer is no. In both cases, as soon as some
container membership property occurs in the input, you'll get true.

You do get a true/yes answer, however, for variable&bnode free
variants, e.g., with BGP
ASK WHERE { rdf:_1 rdf:type rdfs:ContainerMembershipProperty }
over the empty graph, you do get true.

None of this is ideal, but there is no ideal solution. The only thing
we can discuss is: what is the best compromise. I can live with the
current compromise and I personally prefer it over the one where I
implicitly add some fake triple because a) it is cleaner and b) for
the case Axel describes below.

> Hmmm, tricky
>
> First, I suppose
>
> ASK WHERE { ?X rdf:type rdfs:ContainerMembershipProperty}
>
> shouldn't behave different from
>
> ASK WHERE { _:x rdf:type rdfs:ContainerMembershipProperty}
>
> (it doesn't in the current spec, AFAIR, right Birte?)

correct

>
>
> So, as far as we are concerned, Jos' example boils down to:
>
> SELECT * WHERE { ?X rdf:type rdfs:ContainerMembershipProperty}
>
> By definition of my understanding of an "entailment regime" in SPARQL,
> an ASK query can give a positive answer if and only if the corresponding SELECT *
> query would return a non-empty answer. However, there is no bnode identifier
> in the data which would warrant an answer. Answers to ASK queries are just
> like SELECT queries depending solely on BGP matching (i.e. existence of a solution for the BGP)
> in SPARQL... to my understanding,  we have to deal with this "limitation", so, if you want,
> the kind of Boolean queries that Jos is looking for are not necessarily possible in SPARQL.

You could assume that there is always at least one container
membership axiomatic triple available, but that is more like a hack
and not very clean.

Birte

> Hope it is clear what I meant to explain here...
> I think we have a thin line between pragmatic/intuitive for what
> behaviour we can choose for those corner cases... but it should be consistent.
>
> Axel
>
>
> On 24 Feb 2010, at 12:39, Jos de Bruijn wrote:
>
>>
>>
>> On 2010-02-24 13:34, Birte Glimm wrote:
>> > [snip]
>> >>> 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).
>> >
>> > What do you mean with one representative. Can you give an example? I
>> > don't see what problems queries with blank nodes cause here. Maybe I
>> > am overlooking something?
>>
>> If you have a yes/no query:
>>
>> _:x rdf:type rdfs:ContainerMembershipProperty
>>
>> on the empty graph I am assuming one wants the answer "yes". If you do
>> not consider any of the axiomatic triples concerning the container
>> membership properties, the answer would be "no".
>>
>> If you were to always consider the axiomatic triples pertaining to at
>> least one container membership (or perhaps just a blank node), you are
>> guaranteed to get the answer "yes" in this case.
>>
>>
>> Jos
>>
>> >
>> > Birte
>> >
>> >> 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
>>
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Wednesday, 24 February 2010 14:21:36 UTC