Re: on behalf of sandro

From: Deborah McGuinness (
Date: 10/24/01

Richard Fikes wrote:

> >>And then we have the query: "is there anything with any color?", or
> >>RDF(?x, color, ?y).
> >>
> >>Do we get back
> >>
> >>(a) 1 triple
> >>
> >>  <patsCar> <color> <blue>.
> >>
> >>or (b) 2 triples
> >>
> >>  <patsCar> <color> <blue>.
> >>  _:b <color> <red>.
> >>
> >>(where I've changed the _:a to _:b just to emphasise that it is an
> >>arbitrary term, and its scope does not carry over from the knowledge
> >>base to the response).
> >>
> >>or (c) 2 triples with genid (skolem constant)
> >>
> >>  <patsCar> <color> <blue>.
> >>  <reasonerCreatedSymbol79878687> <color> <red>.
> >>
> >>If everyone actually is happy with (b), then we were in fact in
> >>violent agreement.  If not, then there's a real issue here.
> If we accept that we can say in rdf "exists x (RDF(x, color, red))",
> then I indeed have been arguing for (a) rather than (b) or (c).
> It seems to me that (b) and (c) are saying that we will allow an answer
> to a query to contain a binding of a query variable to a constant
> created to represent an existential variable.  As I think Pat is
> pointing out, that makes sense only if the answer is constructed so that
> it is clear which constants represent existential variables, and that
> for query body instances to be entailed by the KB, the constants in the
> answers that represent existential variables need to be appropriately
> replaced by existential variables.
> I am ok with that scheme, and so could agree to query variable bindings
> in answers that are identified as being gensyms representing existential
> variables.
> Just to check, I presume this would apply to cardinality restrictions as
> well.  For example, if the KB says that persons have exactly two values
> of property "parent" (because of a cardinality restriction), the KB does
> not identify Pat's parent, and we ask the query RDF(Pat parent ?x), then
> I presume the complete set of answers would be the triples (Pat parent
> _:p1) and (Pat parent _:p2) (or the bindings {[?x _:p1]} and {[?x
> _:p2]}) where _:p1 and _:p2 are noted to be existentials.

In general, i support getting back existential variables so that we know
that indeed there is something with color red even if it does not have a
name yet.

There are subtleties here though.
to modify your example of parents - lets say that we are using qualified
number restriction and someone says that pat has one parent that is a FOO.
there is another statement that pat has one parent that is a BAR.
if we know that FOO and BAR are disjoint, then we know that Pat has two
parents and then
I would want something like
(Pat parent_:p1) and (Pat parent _:p2)   (where i have the option of getting
followup information about _:p1 to find out that it must be a FOO and also
_:p2 where i can find out that it must be a BAR.

if we do not know that FOO and BAR are disjoint, we might still give the
same answer  however at this point
we do not know if pat has one parent that is both a foo and a bar or if pat
has two parents.

thus, it would seem misleading to give the answer above without an explicit
statement somewhere that
_:p1  could be the same as _:p2 (and if so, then it is both a FOO and a BAR)

and if they are not the same then one is a foo and the other is a bar

along this line of reasoning, in my thesis on explaining description
logics,  i wrote provided algorithms for generating "closed" individuals -
i.e., objects that had a skolem individual as a filler of any role that had
not yet met its cardinality restriction.  the algorithms worked for CLASSIC
(a subset of DAML+OIL) and considered the case where one determined that two
skolems were actually the same object and thus needed to be merged.

if anyone wants details, it is in chapter 5 (on generating examples and
counter-examples) of

> Richard

 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801
705 0941

This archive was generated by hypermail 2.1.4 : 04/02/02 EST