From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 10/24/01
>>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.
Richard
This archive was generated by hypermail 2.1.4 : 04/02/02 EST