This document gives a brief overview of the XML syntax of DQL. It is not intended for casual readers; most people can simply use one of the software toolkits to generate and parse DQL. However, if you want to make one of those toolkits, or if you have an interest in how DQL works, then this document is for you.
If you're looking for background on DQL and a description of the overall operation, please see the abstract specification.
If you're really hard core, you can jump straight to the XML Schema document we put together for DQL messages. Keep in mind, though, that there still is no XML Schema document for either RDF or DAML, as these languages use structures that are not describable by XML Schema. Therefore, if you pass a DQL message through a validation service, you will get errors about tags from the "rdf", "rdfs", and "daml" namespaces being undefined.
DQL follows a simple request-response model. The querying agent, or client, issues a query to the answering agent, or server. As with P2P networks, the notions of client and server become blurry, because agent #1 may ask agent #2 for an answer, who may then turn around and ask agent #3 for an answer to relay to agent #1.
Our DQL XML mapping places the messages into SOAP Envelopes, with the Header and Body tags.
We'll look at this example to illustrate a simple DQL message exchange:
If C1 is a Seafood Course and W1 is a drink of C1, what color is W1? P: (type C1 Seafood-Course) (drink C1 W1) Q: (has-color W1 ?x) must-bind ?x A: White
In our answer KB, that is, the KB that this query is being asked againt, we have this section::
<rdfs:Class rdf:ID="SEAFOOD-COURSE">
<daml:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="#DRINK"/>
<daml:toClass>
<daml:Restriction>
<daml:onProperty rdf:resource="#COLOR"/>
<daml:hasValue rdf:resource="#WHITE"/>
</daml:Restriction>
</daml:toClass>
</daml:Restriction>
</daml:subClassOf>
</rdfs:Class>
We can see that this class, SEAFOOD-COURSE, has a restriction on the property DRINK. The DRINK for a SEAFOOD-COURSE must be WHITE.
Let's walk through the tags used to ask this question. First is some SOAP tags:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
Next is what we care more about: the query message. The outermost tag is "query", in the "dql" namespace.
<dql:query xmlns:dql="http://www.daml.org/2002/10/dql-syntax#"
xmlns:var="http://www.daml.org/2002/10/dql-variables#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#">
This tag defines a number of namespaces that we might find useful later, such as the RDF namespace, the RDF Schema namespace, and the DAML namespace. If we use these later in the document, we will not need to define them again.
Next is a definition of our premise, which as you'll recall, is "Suppose there is a seafood course, named C1. It has a drink named W1."
<dql:premise>
<rdf:RDF>
<rdf:Description rdf:about="#C1">
<rdf:type rdf:resource="#Seafood-Course"/>
<drink rdf:resource="#W1"/>
</rdf:Description>
</rdf:RDF>
</dql:premise>
We now have to actually ask the question. To do this, we use a tag called "queryPattern":
<dql:queryPattern>
<rdf:RDF>
<rdf:Description rdf:about="#W1">
<has-color rdf:resource="http://www.daml.org/2002/10/dql-variables#x"/>
</rdf:Description>
</rdf:RDF>
</dql:queryPattern>
There are a few things to note about queryPatterns. First, any "source" or "object" (the rdf:about and rdf:ID tags, or the rdf:resource tag) may specify a URL with the DQL-Variables prefix. This designates it as a variable. The variable name is then everything after the DQL variables namespace. In this case, the variable is named "x". Note that one may also use a variable as the predicate, that is, instead of "has-color", we could use "var:y" to specify that there is a variable called "y" and to find out what predicates and predicate values are available for W1.
DQL allows the specification of particular variables as requiring a value, and others as maybe having a value. In this case we definitely want a value for our answer, so we provide a mustBindVars section. If we want to specify that some variables may be bound or they may not be, we add a section called "mayBindVars".
<dql:mustBindVars>
<var:x/>
</dql:mustBindVars>
We now have to tell the server what KB to use to answer the question. To do this, we specify a reference to a KB, which is a DAML file available on the Web:
<dql:answerKBPattern>
<dql:kbRef rdf:resource="http://ontolingua.stanford.edu/wines.daml"/>
</dql:answerKBPattern>
Note that we may also specify a KB here, by having a "rdf:RDF" tag and a snippet of DAML. We may also specify a variable here, such as "var:kb", which will mean that the server will find a KB for us and tell us in the answer bindings which KB it used for the answer
Finally, our question in this case is simple, but in other cases, we might give a question that has a lot of answers. We might not care about them. In that case, we need to limit the size of the answer set. To do that, we use the answerSizeBound tag.
<dql:answerSizeBound>5</dql:answerSizeBound>
That's it for the query:
</dql:query>
A query performs some processing on the server, and produces a set of answer bundles. As mentioned in the DQL abstract specification, a server may divide up its answers into bundles separated by continuation tokens. In this example, we'll follow a simple model and have a single termination-token at the end, meaning that the server gave all of the answers.
<dql:answerBundle xmlns:dql="http://www.daml.org/2002/10/dql-syntax#"
xmlns:var="http://www.daml.org/2002/10/dql-variables#">
The query pattern is repeated, verbatim, in the answer:
<dql:queryPattern>
<rdf:RDF>
<rdf:Description rdf:about="#W1">
<has-color rdf:resource="http://www.daml.org/2002/10/dql-variables#x"/>
</rdf:Description>
</rdf:RDF>
</dql:queryPattern>
Next in the bundle is a set of dql:answer tags:
<dql:answer>
Each answer tag contains two entries: A required binding set, which is empty if the query had no variables but succeeded anyway, and an optional answerPatternInstance tag, which contains the query pattern with the variables filled in.
<dql:binding-set>
<var:x rdf:resource="#White"/>
</dql:binding-set>
<dql:answerPatternInstance>
<rdf:RDF>
<rdf:Description rdf:about="#W1">
<has-color rdf:resource="#White"/>
</rdf:Description>
</rdf:RDF>
<dql:answerPatternInstance>
That's it for each answer:
</dql:answer>
Once the server is done giving answers, it sends a continuation which in this case contains a termination token. The termination token is none, which indicates that the server has sent all of the answers that it knows about for this query.
<dql:continuation>
<dql:termination-token>
<dql:none/>
</dql:termination-token>
</dql:continuation>
And that's it for the answer bundle:
</dql:answerBundle>
That's all for our walkthrough of DQL syntax. We suggest using our software for further experimentation.