From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 07/23/02
> The current DQL spec says: > > A DQL query contains a "query pattern" that is a collection of > DAML+OIL sentences in which literals and/or resources have been > replaced by variables. > > As I mentioned in the telecon, I believe that it may be difficult to > give sense/meaning to arbitrary sentences and replacements. Given the ongoing concerns and discussions about the semantics of DAML+OIL vis-a-vis its embedding in RDF, and given that the future is OWL rather than DAML+OIL, I don't think this issue is worth much of our energy. Also, Pat's revision of the DQL spec attempts to finesse this issue by allow servers to publish the class of query patterns that they support. If we agree on that revision, then I think the issue is mote. I will simply state here that in our work with JTP, we have taken seriously the notion that a DAML+OIL KB is a collection of RDF triples, we use the axiomatic semantics for DAML+OIL, and we allow any element of any triple in a query pattern to be a variable. Given that query answering is being defined as finding uri-refs or literals explicitly mentioned as terms in the KB or defined as terms in DAML+OIL, the semantics of such queries (at least based on the axiomatic semantics) and of what constitutes an answer to such queries seems to be clearly and precisely defined. > Peter suggested range(P,v) > and domain(P,v), but the semantics here are not quite so clear - are > we asking about syntax, or do we mean something like "the biggest > class C s.t. onProperty(P),toClass(NOT C)) is inconsistent? (I doubt > that, in general, there exists a unique answer the latter kind of > query; in fact such queries may very well be undecidable.) I don't understand why the semantics are not clear. The semantics of "domain" and "range" are clear, and any class explicitly mentioned in the KB that a reasoner can infer is a domain or range of P is an answer to the query. > I meant to exclude query elements like onProperty(x,y), unionOf(x,y), > which have doubtful/uninteresting semantics from a DAML+OIL point of > view, and could be seen more as "syntax queries", i.e., queries > regarding the syntactic content of the ontology. The semantics of such triples is clear if one assumes that a restriction is a class like any other class and that lists are objects in the domain of discourse. That's what we did in the axiomatic semantics and that's what we do in JTP. > What I was trying to suggest was that some of the properties (and > maybe some of the classes) in daml+oil.daml would not lead to such a > clear semantic account of query element bindings. E.g., for > unionOf(C,w), where C is some class, what would w bind to? W would bind to any list explicitly mentioned in the KB. > If queries > are to have a well defined semantics, then we need to decide how to > handle these cases. That isn't a problem using the axiomatic semantics. > There are some subtle problems here. E.g., if RDFS is used to generate > a subProperty P of sameClassAs, how is P treated in DAML+OIL queries? > According to the current (model theoretic) semantics, if I write > P(C,D), then a DAML+OIL reasoner would NOT infer sameClassAs(C,D). Well, it seems that sameClassAs(C,D) is the clear intention. The axiomatic semantics would sanction that inference. I haven't been a part of the debate of that issue, but at first blush, that sounds like an inadequacy of the model theoretic semantics specification. The bottom line here is this. I don't expect you or the committee to agree with the meaning attached to arbitrary triples in query patterns with arbitrarily placed variables that is given to such queries by the axiomatic semantics. However, I hope that you agree such meaning and such queries are coherent and perhaps even useful. A major payoff to allowing queries with arbitrary triples with arbitrarily placed variables is that it greatly simplifies the specification of the query language. The relatively straightforward description of what a query is and what an answer is that is in the current DQL specification is then sufficient. We can rejoin this discussion with respect to OWL when its specification has been agreed on. Richard
This archive was generated by hypermail 2.1.4 : 07/23/02 EDT