DIG 2.0 RoadMap
- This version:
- $Date: 2006/09/11 09:49:26 $
- Author:
-
Sean Bechhofer,
University of Manchester
A roadmap for DIG 2.0 development.
This document gives a roadmap for DIG Working Group activity relating the production of a new, updated DIG Interface. This is not a definitive plan, but provides an initial "straw man" for discussion within the DIG Working Group.
For the sake of brevity, this document will tend to use the term DIG to refer to the DIG interface.
The DIG interface specification [DIG, DIG1.0] was introduced in order to provide a common interface to DL reasoners. The specification has been updated, but the current DIG 1.1 specification [DIG1.1] has a number of known flaws (e.g. see [Dickinson]). We propose to address these in an updated version of the specification, which will be known as DIG 2.0. The intention is not that this will make radical changes to the interface, but will rather fix the known problems and attempt to provide sensible extensions points.
DIG is not intended to be a general interface to a reasoning service. Rather, it provides a (relatively) lightweight mechanism for tools to interact with a Description Logic reasoner. Issues such as client management, transactions, persistent storage etc are not covered by the spec.
Nor is DIG intended to provide a general interface to an OWL reasoner. The language that DIG 2.0 will support will allow tools that work in the OWL (DL) space to make use of a reasoner, but DIG will continue to use a bespoke concept language. Although this may requires DIG client tools to translate from OWL to the DIG language, this is, in general, a relatively simple translation. Using OWL as DIG's language (in particular using OWL's RDF/XML syntax) is likely to introduce a significant overhead for DIG. Using a bespoke language also ensures that the language is in the control of the DIG WG.
We assume that implementers of reasoners are prepared to commit to supporting the changes that we propose (modulo consensus on the decisions reached — as already stated, this is a straw man). Without such a commitment, the specification is likely to be of limited use.
The following list contains a broad (but probably non-exhaustive) list of requirements for DIG 2.0
Definition of an XML Schema for the concept language. To include at least the expressivity required to support OWL DL + QCRs, e.g. SHOIQ plus support for XML Schema datatypes. Inconsistencies with the relation/property types supported by DIG and OWL/SHOIQ need to be addressed.
02/12/05 After some discussion, the proposal is that the DIG specification will identify a number of concept/role operators that will be supported by DIG (some superset of SHRIQ). These operators will *not* be extensible. A number of pre-defined language fragments will be identified, e.g. ALC, SHOIQ etc., and these will be used by reasoner implementations to identify the fragment that the reasoner understands. Reasoners will not be allowed to defined arbitrary fragments. This provides a compromise between the flexibility of providing "pick'n'choose" expressivity and the horror of having to deal with negotiation.
14/12/05 See below for candidate elements in the language.
Definition of an XML Schema for the tell/ask language. Questions of (richness of) query language are as yet unresolved. The current spec provides simple queries for subsumption testing, consistency checking and instance retrieval. DIG 2.0 is likely to continue with this in the short term.
02/12/05 DIG will support the "traditional" DL style reasoning operators. There was some discussion as to whether we should consider supporting a general "entailment" inference (cf. OWL), but this was rejected in favour of the DL style. We need to identify the core reasoning tasks that will be supported (e.g. subsumption, consistency, instance retrieval), along with any additional non-standard inferences such as LCS etc.
14/12/05 See below for candidate elements in the tell/ask language.
Definition of sensible error handling mechanisms (replacing the existing use of HTTP error codes).
02/12/05 A suggested approach is to provide a small number of top level error conditions e.g. syntax error, internal reasoning error (for example out of memory) etc. Each of these top level errors would then include more specific information, that may be pertinent to a particular reasoner.
Distinguishing between query over told/inferred information.
02/12/05 Opinion is split here. One camp are of the opinion that, in the main, answering queries over told information is not the responsibility of the reasoner. However, there are possibly situations where it is useful to get information from the reasoner. For example, when attempting explanation. Another camp were keen to be able to access the told information, but the problem here is in identifying exactly what we mean. CFP for query over told information (use cases, queries, intended semantics).
Support for compression in DIG messages. XML is a verbose format and large KBs require a lot of information to be transferred over the wire.
02/12/05 Universal support
Provision of simple rollback/checkpoint mechanisms. This is not intended as sophisticated transaction management, but the addition of basic rollback/checkpoint would help to support undo operations, "what-if" experiments, and ease time spent when handling large ontologies. There is a proposal from Manchester that we might consider supporting an operation that provides some (opaque) object encapsulating the current state of the reasoner that can be stored at the client end and recommunicated at a later date. Such an object would be valid for a specific reasoner implementation.
02/12/05 There was some question as to how much guarantee a reasoner would provide that rollback would be possible (e.g. if you wait too long or add too many facts after checkpoint, the reasoner may not allow rollback). There was also interest in the "Manchester proposal" (but some disappointment that there wasn't actually more than the three lines in this document).
Mechanisms for control of core reasoner options.
02/12/05 We may wish to provide a core set of options (UNA on/off etc) but this wasn't seen as a key priority.
Extensibility. There is a clear need for extensibility in DIG. Both in terms of concept language (e.g. allowing reasoners to support additional concept forming operators) and in tell/ask functionality (supporting extended querying). The specification needs to provide a mechanism that allows reasoner implementers to:
02/12/05 Discussion 1. & 2. dealt with issues of extensibility. The consensus was that we would not allow arbitrary extensions to be negotiated between client and server. Everything is in the spec. There may be elements of core functionality along with extensions that some reasoners could choose whether to implement, but arbitrary ad-hoc extensions will not be supported. There was some concern that this would not be enough. CFP for extended functionality and potential use cases calling for arbitrary unforeseen extensions.
Most of these are basic fixes to the existing specification that we have. I would hope that we could address the bulk of these (in particular the definition of the basic concept language and tell/ask) by January 2006.
Things that we might also expect to see at a later date:
Listed below are candidate elements for the basic DIG 2.0 concept language.
Atoms describe atomic concepts, properties and individuals.
DIG 1.1 included a distinguished element for the top and bottom concepts. This introduced inconsistency in the way that concept expressions were handled. The DIG 2.0 schema does not contain explicit elements for top and bottom. Instead, top and bottom are represented using concept elements with distinguished names. @@TBD: Names for Top and Bottom@@.
Role quantification operators such as some and all are not distinguished as to object/data properties. Operators such as some and cardinality restrictions can take an optional qualification.
To be decided. See http://protege.stanford.edu/plugins/owl/xsp.html for inspiration.