DIG 2.0 proposal for the standard extension: Non-standard Inferences

This version:
http://lat.inf.tu-dresden.de/~turhan/NSI.html
Authors:
Anni-Yasmin Turhan, Dresden University of Technology
Yusri Bong, Dresden University of Technology

Abstract

this document is a proposal for a standard extension and an interface for non-standard inferences for DIG 2.0. Currently, this proposal is under construction.


Contents


Introduction

Non-standard inferences (NSI) are more and more recognised as useful means to realise new kinds of applications. The number of applications that use non-standard inferences in their framework is growing. To implement these kinds of applications it is desirable to make use of existing implementations of NSIs. In order to have easy access to the implementations of the NSIs, an extension of the DIG interface to NSIs is desirable. There are different NSIs investigated and developed by different research groups. This extension proposal focuses on the NSIs studied at the TU Dresden. However, the extensions for NSIs are not restricted to this set of inferences. For an overview of the non-standard inferences covered here please see [NSIs]. So far all of the here proposed NSIs are the ones implemented in the system SONIC. We try to propose a general scheme here for NSIs, but at this stage the proposal is still quite tailored to this system.

The terminologies acceptable as input for most of the NSIs covered here are currently restricted to unfoldable (i.e. acyclic and with unique definitions) terminologies and to a set of concept constructors that is in most cases restricted to the set of sub-boolean operators plus (unqualified) number restrictions.

Requirements

We have a couple of technical requirements for the environment in which our NSI extension operates. The NSI component works as a DIG server for the application and as a DIG client, since tests for satisfiability and subsumption are needed during the computation of the NSIs as well as access to told information to retrieve the concept definitions of concept names. To avoid duplicate storing and classifying of the KB and to ensure that the NSI component works on the identical KB as the application, the NSI component must use the same instance of the DL reasoner as the application. This way it is guaranteed that the NSI component always works on the current version of the KB even in case the application has re-submitted an edited version of the KB.

In its current implementation the SONIC NSI component is a stand-alone application that is invoked by the application and connects to the same instance of the DIG DL reasoner as the application. It gets the port number etc. from the application. For the forthcoming version of DIG our NSI component also needs a connection to a component that implements the told information access interface as specified by the proposal for accessing told data. We assume here that one connection suffices to access both, the told information component and the core DIG reasoner, which can either be realised by a core DIG reasoner supporting the told information access interface or by the middle-ware reference implementation of the DIG group.

Besides the information for the connection the NSI component needs the URI of the knowledge base that is loaded into the reasoner. Thus the URI of the KB must be transmitted as an identifier.

In contrast to standard reasoning tasks, most NSIs return complex concept descriptions and not only Boolean values. Furthermore the NSIs take into account the "target DL" for which they are applied. For example concept approximation "translates" concept descriptions from one DL L1 to another DL L2. Thus the NSI extension schema must provide means to communicate the respective DL.

To sum it up, our NSI component needs the following information

The supported NSIs

The operators offered by our NSI extension are enlisted and explained in the following. First we give an abstract pseudo-LISP style syntax to illustrate the use of them. These inference services will be offered as ask statements in the XML schema. The whole NSI extension schema can be found here.
However, this list is surely not complete and this proposal is open to be extended by other NSIs such as, for example, explanation.

The XML schema for the NSI extension

Our NSI extension schema mainly focuses on the two following aspects: The most queries require concept descriptions as input or produce concept descriptions as output. These are to be specified according to the DIG core schema. The whole XML schema for the NSI extension can be found here.

A. Ask Statements

The ask statements use parts of the DIG core schema and provides the group nsiQueries with elements that are likely to be useful for other NSIs or inference services that are not yet incorporated in DIG or one of its extensions. The root of NSI requests is the tag <asks>. Thus all NSI queries are children of this element. A request may contain several queries. As stated in the Requirements the NSI reasoner needs some information about other components. This information is provided by the following attributes of the ask element: It is necessary to pass this information in each NSI request, since the DIG protocol is stateless. Each request contains at least one query. The schema for a NSI request is the following:
<xsd:element name="asks">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:group ref="nsiQueries" minOccurs="1" maxOccurs="unbounded"/>
        </xsd:sequence>
        <xsd:attribute name="machineName" type="xsd:string" use="optional" default="localhost"/>
        <xsd:attribute name="port" type="xsd:int" use="required"/>
        <xsd:attribute name="kb" type="xsd:string" use="required"/>
    </xsd:complexType>
</xsd:element>
The subelement of <asks> is an element of the group "nsiQueries". The elements of nsiQueries are elements that represent "ask" query types for the NSI services. Although currently limited to the ones available in SONIC, the idea is to specify query types that might be useful for other NSIs or even other services. Before turning to the schema, we would like to explain the idea behind the new types and their naming: These types are used in the following way in the schema:
<xsd:group name="nsiQueries">   
   <xsd:choice>
   <xsd:element name="approximation" type="basicTargetDLClassAsk"/>
        <xsd:element name="findMatcher" type="findAssignmentsAsk"/>
        <xsd:element name="findMatchingConcepts" type="findAssignableConceptsAsk"/>
        <xsd:element name="lcs" type="basicTargetDLClassSequenceAsk"/>
        <xsd:element name="gcs" type="basicTargetDLClassSequenceAsk"/>
        <xsd:element name="minimalRewriting" type="ask:basicClassAsk"/>
    </xsd:choice>
</xsd:group>

Next, we will see the type for each NSI service that is provided by our extension. Note, in the following we use notions from these "base schemas":

In fact all tags extend the basicClassAsk from the core DIG 2.0 ask schema.

Since most NSIs need a target DL as input, the queries must specify these. The target DL language should be specified in string format in the attribute targetDL. We propose to chose this string according the DL community's naming convention for DLs — such as "EL" or "ALEN". An alternative would be to specify the DL in a separate schema that is then used as a URI in the NSI extension. However, if the core DIG 2.0 schema will provide a standard for naming DLs, then we will use that standard in our extension. In addition, as in the "standard" ask in the core DIG, each query has an attribute id for identification in the response.

A.1 Ask statement for Approximation

The subelement of this tag is the concept description for which the approximation has to be computed and the target DL in the attribute target.
<xsd:complexType name="basicTargetDLClassAsk">
    <xsd:complexContent>
        <xsd:extension base="ask:basicClassAsk">
            <xsd:attribute name="targetDL" type="xsd:string" use="required"/>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

A.2 Ask statements for LCS and GCS

These two queries have the same type: basicTargetDLClassSequenceAsk. The subelement of this tag are (at least two) concept descriptions. The user must also state the target DL for the LCS or GCS in the attribute target.
<xsd:complexType name="basicTargetDLClassSequenceAsk">
    <xsd:complexContent>
        <xsd:extension base="ask:basicAsk">
         <xsd:sequence>
            <xsd:group ref="lang:description" minOccurs="2" maxOccurs="unbounded"/>
        </xsd:sequence>
        <xsd:attribute name="targetDL" type="xsd:string" use="required"/>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

A.3 Ask statement for Find Matcher.

The subelements of this tag are a concept description followed by a concept pattern.
<xsd:complexType name="findAssignmentsAsk">
    <xsd:complexContent>
        <xsd:extension base="ask:basicAsk">
            <xsd:sequence>
                <xsd:group ref="lang:description"/>
                <xsd:group ref="conceptPattern"/>
            </xsd:sequence>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

A.4 Ask statement for Find Matching Concepts

The subelement of this tag is a concept pattern.
<xsd:complexType name="findAssignableConceptsAsk">
    <xsd:complexContent>
        <xsd:extension base="ask:basicAsk">
            <xsd:group ref="conceptPattern"/>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

A.5 Ask statement for Minimal Rewriting

The only subelement of this tag is the concept description that is going to be rewritten, thus we can use "basicClasAsk" from the ask schema and don't need an extension for this service.

B. Response Statements

?: Tag nsiResponse for grouping responses?
Since the core DIG does not yet have a response schema this proposal is quite preliminary and will evolve as the DIG response schema evolves.
Every individual response has to include the id of the query it refers to. Most of the services that NSI reasoner provide return (a set of) concept descriptions. These (sets of) concept descriptions should be handled according the core DIG 2.0 schema. Thus we do not propose a formal and complete schema for this kind of response. Instead we just give a proposal of valid XML document for this kind of response in the example section.
The only reasoning service that does not return a set of concept descriptions is "Find Matcher". This service returns a (possibly empty) set of of matchers, i.e, assignments, which are pairs of variables and concept names. So, we need a schema definition for a set of assignments, which is then refined to a set of matchers.
<xsd:complexType name="basicAssignment">
    <xsd:sequence>
        <xsd:element name="variable" type="lang:named"/>
        <xsd:group ref="lang:description"/>
    </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="basicAssignmentsResponse>
   <xsd:sequence>
      <xsd:element name="assignment" type="basicAssignment" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
   <xsd:attributeGroup ref="ask:basicAskAttributes"/>
</xsd:complexType>
<xsd:element name="matchers" type="basicAssignmentsResponse"/>

The complete definition of our proposal of NSI extension schema can be found here.

NSI Examples

This page illustrates the use of the inferences by providing sample KBs, queries and the responses.

Open Issues



References

[NSIs]
Using Non-standard Inferences in Description Logics — what does it buy me?
[GCS]
Computing the GCS w.r.t. a Background terminology.


Anni-Yasmin Turhan
Last modified: Thu Sep 7 15:23:17 CEST 2006