From: Richard Fikes (email@example.com)
Attached below is an excerpt of a message I recently sent to Pat and Ian. I don't expect you to have read it before the telecon, but I want you to have it so that I can refer to it in today's discussion of DQL. Richard --------------------------- I said earlier: > There are several issues being discussed together in the recent e-mails > and telecons regarding DQL that I think are separable. One issue is the > definition of a minimal identifying description (MID) for a node in an > RDF graph. A node's MID is independent of any particular use of the > MID. In particular a node's MID is independent of its use in a query > answer. So, we can decide on a definition for a MID independent of > DQL. We now actually have two definitions of a MID. I think they are equivalent and that they formally define the graph that we have in mind. So, even though Peter thinks they are silly, I think we now have MIDs if we want to use them. The more serious issue that Peter has raised, in my opinion, is independent of whether we use MIDs or not. Here are three KBs taken from his examples that I think capture the essence of the problem: KB1 John rdf:type _:r . _:r daml:onProperty friend . _:r daml:minCardinality 1 . KB2 John friend _:f . KB3 John friend Bill . KB1 entails the sentence "(exists ?x (friend John ?x))", but does not explicitly contain that sentence. KB2 explicitly contains that sentence. KB3 explicitly names a friend of John. Consider asking the following query: > Query John friend ?l . > ?l distinguished We have been saying that query answers have to be entities that are explicitly referenced in the KB. In KB1 above, there is no explicit reference to a friend of John's. In KB2 and KB3, there is an explicit reference to a friend of John (i.e., _:f and Bill, respectively). Therefore, according to the current DQL spec, the query would have no answers from KB1 and would have one answer from KB2 and one answer from KB3. Peter says > It seems exceedingly > strange that two equivalent KBs can give rise to different answers to a > query. I view this a fatal problem that must be solved.
This archive was generated by hypermail 2.1.4 : 06/04/02 EDT