From: tim finin ([email protected])
Date: 08/20/02
pat hayes wrote: > Er..guys, I havnt looked at the details of this, and maybe I have > misunderstood what you are doing; but there seems to me to be > something fundamentally wrong with the very idea of having an > ontology for queries. > ... I felt a little odd calling it a DQL ontology. What we are doing, of course, is developing a way to *encode* DQL query objects (and their responses) in DAML+OIL. In building our multiagent systems we are trying to use DAML+OIL and RDF as the representations of choice. We are also following the FIPA model, which requires conventional ways to encode certain things (e.g., propositions, actions, queries) for any FIPA compliant content language. The actual query, of course, is the use of the appropriate speech act with content describing a query object. Part of our research agenda is to explore how semantic web languages can be used in multiagent systems. Our strategy is to use them promiscuously and thereby find out where they provide real value and where they just cause problems. Many of these things can only, IMHO, be determined through experimentation. A few final comments on using DAML+OIL to encode DQL queries: DAML+OIL is not the *ideal* language for describing the query object (in fact, I doubt that it's the ideal language for describing anything). It does allow us to capture some aspects of DQL, such as cardinality constraints on the DQL components. Using DAML+OIL to encode DQL queries provides a good way to publish query objects in web pages and other documents and to store them in databases and knowledge bases. If DQL queries or at least query objects are represented in DAML+OIL it will facilitate reasoning *about* the queries. There are times when you might want to do this, such as for query optimization or to prove that one query object "subsumes" another. Following these arguments to their logical conclusion suggests we should use DAML+OIL to encode things at the speech act level. For practical reasons, I'm not suggesting we do that yet, but we might at some point. Tim
This archive was generated by hypermail 2.1.4 : 08/20/02 EDT