A proposal for an interface for extensibility within DIG 2.0.
What the extension mechanism IS
Providing an extension mechanism within the DIG specification allows
reasoners to provide more specific services beyond the core-tell
and -ask functionality. Since DIG is designed to cover only the common
functionality of many reasoning systems, most of them very likely offer
further functionality. In this proposal extensions are intended to
provide a very flexible way to add new functionality within the scope
of the DIG interface. Current candidates for extensions are
non-standard reasoning services such as debugging or explaining and
query languages. For instance, without extensibility each reasoning system which offers
a more-fine graded query language (such as RACER's nRQL) needs at least two different
communication channels and interfaces, namely DIG and a native reasoning API .
As the DIG interface is considered as a standard interface for accessing DL
reasoning systema, it is a desirable goal not only to standardize the core DIG
but also extensions. However, it is not possible to put all kinds of useful extensions
and operators into the DIG specification in advance because of evolving and upcoming work
in the context of non-standard inference services and reasoning related services.
We therefore propose a common extensibility mechanism which should distinguish between
standardized and non-standardized (say "non-official") extensions as shown
in figure 1. These extensions should not be limited only to
ask operators but also support tell operators as some tell operators (maybe we need to
find a better word for it because there are no "real" tell operators wrt. the knowledge
base) are useful e.g. for management operations (save a knowledgebase in a
reasoner-dependent format) or for subscribing to a publish-subscribe mechanism.
Fig. 1. Conceptual overview of extensibility within DIG
What the extension mechanism is NOT
It should not be allowed for either overloading core DIG-statements
with additional information or alter the semantics of the core tell and ask
statements.
We propose a modularized DIG not only from a conceptual perspective but
also from an implementational one (especially for upcoming non-standard
DL inference services). Therefore, an extension is defined by an XML Schema
for the supplementary fraction of the tell and ask language. It will be identified
via an unique identifier, namely an URI. We suggest that URIs
of the so-called standardized DIG extensions start with the DIG URI prefix, i.e.
"http://dl.kr.org/dig/dig2.0..." (or whatever it will be for DIG 2.0).
A reasoner can announce each supported extensions within a
<supportsExtension/> tag inside the reasoner identification statement
(i.e. <identifier/>) as shown in the extract of the XML Schema
definition in Figure 2). Those will appear within the
<supports/> tag of the reasoner identification.
<xs:element name="identifier">
<xs:complexType>
<xs:sequence>
<xs:element name="supports" type="supportsType"/>
<xs:element name="supportsExtension" type="extensionType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="version" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[0-9](\.?[0-9]+)*"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="message" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:complexType name="extensionType">
<xs:attribute name="name" type="xs:anyURI" use="required"/>
<xs:attribute name="version" type="xs:string" use="required"/>
<xs:attribute name="provider" type="xs:string" use="optional"/>
<xs:attribute name="message" type="xs:string" use="optional"/>
</xs:complexType>
Fig. 2. Extended XML Schema definition for supporting extensibility within the identifier section
As can be seen in the fragment of the XML Schema definition the extension specification
tag (<supportsExtension/>) is optional and can appear several times if
several extensions are supported as shown in figure 3.
<identifier xmlns="http://dl.kr.org/dig..."
xmlns:xi="http://dl.kr.org/dig..."
[...]
<supports>
[...]
<supportsExtension name="http://www.informatik.uni-ulm.de/ki/explanation.xsd"
version="0.1" provider="Ulm University"
message="non-standard inference service for explanation of subsumptions"/>
<supportsExtension [...]/>
</supports>
</identifier>
Fig. 3. Extensibility identification example
From a technical perspective, each extension is specified by an XML schema definition.
However, instead of creating a new XML schema which includes all the operators of the
core DIG schema definition and introduce new XML root elements, we propose to introduces
"extension points" for the tells and asks in the core
schema. An extension typically include the core schema definition and use the extension
points to plug-in new operators.
Therefore there are two elements, namely tells and asks
(as already contained in DIG 1.1), which are associated with the abstract
type aTells resp. aAsks which can only be specialized via
extension (not via restriction) as shown in figure 4. These complex
types will be extended by each extension to allow other operators. Even the core DIG will
extend aTells in a way that it consists of the axioms element.
<!-- element and abstract type: -->
<xs:element name="tells" type="aTells"/>
<xs:element name="asks" type="aAsks"/>
<xs:complexType name="aTells" final="restriction"/>
<xs:complexType name="aAsks" final="restriction"/>
<!-- the core DIG tell statement: -->
<xs:complexType name="coreTells" final="restriction">
<xs:complexContent>
<xs:extension base="aTells">
<xs:sequence>
<xs:element ref="axioms"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Fig. 4. Tells/asks element and abstract tell/ask type
Note that we introduce an abstract type for tells and asks statement instead of
only allowing to extend the coreTells resp. coreAsks because
this is a more flexible way which also allows extensions which need
additional operators around the core DIG operators, e.g. transaction extensions. The core
types can also be extended.
DIG Extensions can define arbitrary tell and ask operators with the following
limitations: It is not allowed to either redefine the semantics of the
core tell and ask operators as well as operators of other extensions, or to
overload core statements (resp. statements of other extensions) with
additional information (e.g. adding XML attributes etc.). Therefore all the
operators of an extensions must be bound to the unique namespace of
the extensibility schema namespace. Note that it is possible that an extension
refers to operators of the core DIG or any other extension by using the XML schema
include operator.
- Negotiation protocol
- As the DIG interface should be considered as a low-level DL-specific
interface we should avoid an explicit negotiation protocol for the discovery
of extensions. If a client would like to use operators of a extension
schema which is not supported by the reasoner, the result would be either an
error (not known operators) or it will be not processed (like not-known
XML tags).
- Official vs. unofficial extensions
-
We distinguish between "standardized" (i.e. "official") and "unofficial" extensions.
The idea therefor is to allow arbitrary extensions (even experimental ones) but also
to have some standardized extensions which the DIG group officially supports and which
are part of the DIG specification. However, the question
arises who will decide what an official extensions is and why (e.g. requirements such
as common usage, DL community demand, concise semantics etc.).
We think that the decision procedure could be part of the DIG working group, or maybe
a subgroup therefrom.
- [DIG1.0]
- Sean Bechhofer. The DIG Description Logic Interface:
DIG/1.0. http://dl-web.man.ac.uk/dig/2002/10/interface.pdf
- [DIG1.1]
- Sean Bechhofer. The DIG Description Logic Interface:
DIG/1.1. http://dl-web.man.ac.uk/dig/2003/02/interface.pdf