The DIG Interface provides an implementation-neutral mechanism for accessing Description Logic reasoner functionality. At a high level the interface consists of XML messages sent to the reasoner over HTTP connections, with the reasoner responding as appropriate.
The DL Implementation Group (DIG) is a self-selecting assembly of researchers and developers associated with implementations of Description Logic systems. One of the main tasks of DIG has been the specification of a standardised interface for Description Logic (DL) reasoners.
The DIG Interface provides a specification of an interface for description logic reasoners. It is intended to be a lightweight mechanism providing access to reasoning functionality. There are many things that a reasoning service may be expected to provide that the DIG interface does not provide — it is expected that a DIG reasoner will be one component within a larger architecture.
This document describes the latest version of the DIG interface. There are a number of enhancements and changes from previous versions. Key changes include:
The interface described here (DIG 2.0) draws on experiences gained from earlier DIG specifications (1.0 and 1.1). However, 2.0 is not intended to be backwards compatible with existing 1.1 implementations.
In the past, description logic (DL) systems have presented the application programmer with a functional interface, often defined using a Lisp-like syntax. Such interfaces may be more or less complex, depending on the sophistication of the implemented system, and may be more or less compliant with a specification such as KRSS [KRSS].
In a distributed, web-based environment, a DL might naturally be viewed as a self contained component, with implementation details, and even the precise location at which its code is being executed, being hidden from the application [SERVERS]. This approach has several advantages: the issue of implementation language is finessed; the API can be defined in some standard formalism intended for the purpose; a mechanism is provided for applications to communicate with the DL system, either locally or remotely; and alternative DL components can be substituted without affecting the application.
In order to address these issues, the Description Logic Implementation Group proposed a new, standardised Description Logic interface (also known as DIG). DIG provides a basic API to a DL system. It is a relatively lightweight interface, and provides just enough basic functionality to allow tools such as ontology editors like OilEd or Protege to make use of a DL reasoner. DIG is not solely intended to support ontology editors, however. Any applications making use of DL reasoning may benefit from DIG. DIG does not intend to provide what we might truly call a reasoning service, but rather helps to insulate applications from the location and implementation language of a DL reasoner. The specification does not address issues such as stateful connections, transactions, concurrency, multiple clients and so on.
DIG uses HTTP as its underlying protocol for communicating with a reasoner. The reasoner accepts HTTP POST requests and responds as appropriate. The contents of the requests are elements defined by an XML schema.
The core DIG specification is an XML Schema [XML Schema] for a DL concept language, ask/tell functionality and a description of a protocol used to communicate these operations (using HTTP). Along with the definition of the interface, however, there is also a commitment from implementors of leading DL reasoners to provide implementations conforming to the specification.
The DIG interface makes a number of assumptions.
Again we reiterate that the specification is not intended as a ``database system'' for knowledge bases. It is simply a protocol that exposes the reasoning services provided by a DL reasoner. A DIG reasoner may be used to implement a service that provides concurrent access, transactions etc, such functionality is not inherently supported by DIG.
The W3C Recommendation for a Web Ontology Language, OWL [OWL] has its roots in Description Logic. The OWL-DL subspecies of OWL corresponds to a DL, and DL reasoners are seen as crucial in providing inference over OWL ontologies. Because of this, the need for a well-defined, consistent, access to DL reasoners is now more important than ever.
There are mismatches between the original DIG specifications, and languages such as OWL, however. The concept language supported by DIG 1.1 does not quite cover the functionality provided by OWL. Thus DIG 1.1 reasoners are unable to completely support applications that make use of OWL DL. This latest DIG interface specification (DIG 2.0) is intended to address these shortcomings and provide a reasoning interface that can support OWL DL. DIG 2.0 looks beyond OWL DL, however, and supports some extended functionality such as Qualified Cardinality Restrictions and role forming operators. In particular, DIG 2.0 will provide sufficient expressivity to cover the extensions proposed in what is being known as OWL 1.1. This is not to say that OWL 1.1 only provides the operators on OWL 1.1, nor that all OWL 1.1 operators will appear in the same format.
The core functionality of DIG 2.0 permits a client to tell the reasoner axioms that make up a knowledge base in a variant of the SROIQDn- Description Logic and pose semantic queries against that knowledge base. [PFPS: Need to check to make sure that Dn- is the correct qualifier.] This Description Logic was chosen for the core of DIG 2.0 because it is the Description Logic underlying the OWL 1.1 language.
As far as DIG 2.0 is concerned, a knowledge base is nothing more than a bag of axioms. A DIG 2.0 server is responsible for parsing the axioms it receives and answering queries against the resultant knowledge base. The server is also responsible for responding appropriately when it encounters syntactic or semantic problems in its input.
The core functionality of DIG 2.0 is completely described in the DIG 2.0 Core document. The XML Schema for the core is provided in the DIG 2.0 Core XML Schema.
Because the DIG 2.0 Description Logic mirrors the OWL 1.1 language it has a couple of unusual features.
One unusual feature of the DIG 2.0 Description Logic is its use of what is generally called "punning". The basic idea is that each name in a DIG 2.0 knowledge base can be used as the name of any or all of a datatype property, an object property, a class, a datatype, and an individual at the same time. However, all five of these uses are completely independent. Note that this is very different from the situation in RDF.
Punning in DIG 2.0 knowledge bases eliminates the need for introducing names in def statements. In fact, the DIG 2.0 syntax has been chosen so that any constructs that use names provide context described how the name is used. (In this way DIG 2.0 is slightly different from the OWL 1.1 abstract syntax.) Therefore the def statements from DIG 1.1 are deprecated/removed?? in DIG 2.0 and DIG 2.0 reasoners are free to ignore such statements.
The DIG 2.0 Description Logic incorporates a datatype feature. As in OWL 1.1, the datatypes here are taken from XML Schema Datatypes. [More is needed here.]
Different Description Logic reasoners support different Description Logics and different reasoning facilities. To partly support these differences, DIG 2.0 provides an extensibility mechanism. There is a document describing the rationale behind the extension mechanism.
A DIG 2.0 extension consists of two documents
Both documents must be available on the web, and their URIs must differ only in their extension. [Note: Can the two documents share a URI and be distinguished by content negotiation?] Although it is not a formal requirement of the DIG 2.0 extensibility mechanism, it is expected that the XML schemas will define the syntax of extensions as extensions of XML schemas for other DIG 2.0 extensions as much as possible.
A standard DIG 2.0 extension is simply an extension whose URI starts with the standard DIG 2.0 URI prefix, namely "http://dl.kr.org/dig/dig2.0/". As can be seen from the above, the core of DIG 2.0 is in the form of a standard DIG 2.0 extension.
It is possible for DIG 2.0 "extensions" to define subsets of the core DIG 2.0 functionality.
In many applications (for example debugging a knowledge base created by several clients) it is useful to be able to access the unprocessed information sent to a Description Logic reasoner.
To this end, one of the standard DIG 2.0 extensions provides the ability to retrieve the information that has been explicitly given to the reasoner ("told") as axioms. The simplest form of this extension returns axioms that explicitly mention at top level a named class, property, or individual.
There is a draft document describing the told access extension.
The core DIG 2.0 functionality builds up a knowledge base monotonically. The only facility for removing information involves starting over from an empty knowledge base. A DIG 2.0 extension provides a simple method for retracting information from a knowledge base.
In this retraction extension, only top-level axioms that had been previously added to the knowledge base can be retracted. The axioms are identified either via identification tags associated with axioms when they were added to the knowledge base or by tags associated with retrieved told information.
There is a draft document describing the retraction extension.
Non-standard Inferences are increasingly recognised as a useful means to realise applications. For example, Least Common Subsumer (LCS) provides a concept description that subsumes all input concepts and is the least specific (w.r.t. subsumption) to do so. A DIG 2.0 extension provides a proposal for an extension supporting NSIs.
There is a draft document describing the NSI extension.
DIG 2.0 uses HTTP [HTTP] as the underlying transfer protocol. In this respect, we borrow from other initiatives such as SOAP [SOAP] and XML-RPC [XML-RPC] which have both built messaging protocols using XML on top of HTTP.
Clients communicate with a server through the use of HTTP POST requests. The body of the request must be an XML encoded message corresponding to a DIG request as described below. Content-Type is text/xml, and the Content-Length must be specified and must be correct.
The server will use the root element of the message body to determine the message type (i.e. CONFIGURATION, MANAGEMENT, ASK or TELL).
Unless there is a low-level error, the server should return 200 OK. As with requests, the Content-Type is text/xml and Content-Length must be present and correct. The body of the response must be an XML encoded message corresponding to a DIG response as described below. Earlier DIG specifications made use of HTTP error codes to communicate reasoner errors. This is no longer supported. If errors are to be reported, this should be done in the body of the response.
A number of CONFIGURATION requests are available. These allow clients to interrogate a reasoner to discover its identity, and adjust settings of the reasoner (such as optimisations).
A client can ask a DIG reasoner for identification through an identification request. The reasoner will return a response that provides information about the reasoner including:
Reasoner implementations may allow the client to select or set various options (such as optimisations to be used during reasoning). The current status of the reasoner can be queried through a status request. This will return a response describing the current status of the reasoner. The DIG specification defines the general format of such responses, but does not provide the specific details of available options — these will be defined on a per-reasoner basis.
Options and settings can be set using a configure request. Again, the specific content of such requests is not defined in the specification.
A DIG reasoner can deal with multiple knowledge bases. Within DIG, URIs are used in order to identify different knowledge bases. When a request is made to a reasoner to create a new knowledge base, the reasoner (if successful) will return to the client a URI which the client can then use to identify the knowledge base during TELL and ASK requests. Knowledge base URIs are guaranteed to be unique, thus a KB URI is valid for that reasoner only — making a request to another reasoner with the same URI will result in an error. The use of unique URIs also allows us to sidestep some of the issues relating to multiple clients. If a client chooses not to share a KB URI with another client, then the client can be sure that it is the only one interacting with the KB. This is not entirely the case, as a malicious client could choose to try sending messages with random URIs to a running reasoner. There is a (very small) chance that such a client could get lucky and hit on a URI which is in use, but this potentional situation is unlikely enough for us not to be concerned with it at this point.
Different clients of the same reasoner, however, may be able to share knowledge bases by sharing URIs — it is then the clients' responsibility to manage and coordinate this sharing.
What about a "standard" KB as discussed recently??
Note that DIG does not explicitly provide any support for modularity or import of Knowledge Bases. Each Knowledge Base presented to the reasoner is a self-contained collections of facts and axioms. Client applications (for example, those using OWL) will thus have to resolve any issues relating to import of Knowledge Bases before passing a KB on to a DIG reasoner.
There are a number of basic MANAGEMENT requests.
Note that the URIs referred to above simply provide a handle that identifies the particular incarnation of the KB in the particular reasoner.
Of course, richer access mechanisms involving, for example, authentication, are likely to be necessary for wider deployment of reasoning services for real-world applications in networked environments. We are aware that our current interface specification (explicitly) ignores this issue in its current form.
DIG 2.0 provides a measure of flexibility in the concept languages that can be supported by reasoners. A collection of concept and role forming operators are defined in the specification. A collection of language fragments are then defined in terms of these concept and role forming operators. A DIG reasoner must advertise which particular language fragment it operates over. Note that a language fragment may involve not only a list of those operators that can be used, but also side-conditions that state how those operators may be combined.
DIG 1.1 provided a mechanism whereby a reasoner could specify its "capabilities" and the concept language it supported through an enumeration of concept forming operators. This was specified in a rather ad-hoc fashion. This capability description is superceded by the mechanism described above. Reasoners cannot now define arbitrary language fragments, but must adhere to those described in the specification. This provides less flexibility, but simplifies the task of determining appropriate sublanguages, In particular, the side conditions for some language fragments mean that any mechanism used to describe fragments on the fly will be (possibly over-) complex.
Details of DIGs core concept and role formation operators are given in the DIG 2.0 Core document. The XML Schema for the core is provided in the DIG 2.0 Core XML Schema.
Language Fragments supported by DIG are described in the table below. Each language fragment describes the operators permitted in the fragment along with possible side conditions describing extra restrictions on the usage of the operators. Note that these side conditions may include information that cannot easily be expressed in the XML schema.
Communication with the reasoner is via messages which encode TELL and ASK functions supported by the reasoner. Concept descriptions should use the language identified above. If a reasoner receivs a TELL containing expressivity which is outside that advertised, an error should be returned.
@@We still need to finalise our terminology here: tells vs. axioms@@
A TELL request must contain in its body a tells element, which itself consists of a number of tell elements. A TELL request must be made in the context of a particular knowledge base (which is identified via an attribute of the enclosing tells element).
The order of tell statements within a single tells operation is unimportant.
The response to a TELL will be a response message containing either an ok element, signifying that the statements were received and interpreted correctly, or an error element which may include an optional error code, message and detailed explanation.
In addition, an ok message may contain warnings about the tells received. For example, a DIG reasoner may accept knowledge bases where primitive concepts are used without being explicitly introduced. However, it may be useful to warn the user if this has happened, as this may indicate a spelling or typographical mistake.DIG 2.0 does not support asynchronous queries.
In general, responses to concept queries such as a request for all parents will return sets of sets of concept names, each set being a collection of synonyms.
One key issue with the specification of an interface is the granularity of the operations supplied. For example, a criticism of the early CORBA-FaCT interface was that in order to construct a concept hierarchy (a common task for applications), the client had to make many requests to the server. This was undesirable due to the overhead involved with communication.
This becomes less of an issue when multiple requests are permitted in a single communication. For example, in order to determine the classification hierarchy, a client need only make two requests: one to determine the concepts in the hierarchy (for example through the use of a descendants or allConceptNames request, and one to determine all the immediate children of those concepts. This information is then sufficient to recreate the hierarchy without further communication with the reasoner.
XML is a verbose format and large KBs may require a lot of information to be transferred over the wire. It has been observed with DIG 1.1 implementations that this can introduce a considerable overhead into the communication process. In order to alleviate this, DIG reasoners will support the use of compression, with message payloads being compressed before transfer
@@How do we plan to do this? Do we get the server to work it out? Use content encoding? And what compression formats do we support? Zip? GZip?@@
The interface described here is, of course, simply a first step towards the provision of reasoners that can be deployed in a component-based architecture. There are many areas in which the specification could be extended. The assumptions described above could be relaxed, in particular to support multiple or stateful clients. The concept language could be extended to cover more expressive DLs. Alternatively we could investigate the provision of a SOAP based interface for better integration in a web service setting.
DIG Working Group