W3C W3C Member Submission

OWLlink:
Structural Specification

W3C Member Submission 1 July 2010

This version:
http://www.w3.org/Submission/2010/SUBM-owllink-structural-specification-20100701/
Latest version:
http://www.w3.org/Submission/owllink-structural-specification/
Authors:
Thorsten Liebig, derivo GmbH (formerly Ulm University)
Marko Luther, DOCOMO Euro-Labs, Munich
Olaf Noppens, derivo GmbH (formerly Ulm University)
Contributors: (in alphabetical order)
Sean Bechhofer, The University of Manchester
Ralf Möller, Hamburg University of Technology
Boris Motik, Oxford University
Michael Wessel, Racer Systems GmbH & Co. KG

This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.


Abstract

The OWLlink interface provides an implementation-neutral mechanism for accessing OWL reasoner functionality. OWLlink is a refinement of the [DIG] protocol most notably with respect to query and language expressivity. It has been renamed to OWLlink since it relies on OWL 2 for the primitives of the modeling language, and is thus fully compatible with OWL. The set of OWLlink core primitives described in this document cover basic reasoner management, assertion of axioms and elementary ask functionality. An extension mechanism is provided to easily add any required functionality in a controlled way to the core language. This document defines the OWLlink core interface by providing a structural specification. A concrete binding into [HTTP/1.1] and [XML Schema] is given in an accompanying document [OWLlink HTTP/XML Binding]. Further bindings are the [OWLlink HTTP/Functional Binding] and the [OWLlink HTTP/S-Expression Binding].

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a part of the OWLllink Submission which comprises eight documents:

  1. OWLlink: Structural Specification (this document)
  2. OWLlink: HTTP/XML Binding
  3. OWLlink: HTTP/Functional Binding
  4. OWLlink: HTTP/S-Expression Binding
  5. OWLlink Extension: Retraction
  6. OWLlink Extension: Retraction HTTP/XML Binding
  7. OWLlink Extension: Retraction HTTP/Functional Binding
  8. OWLlink Extension: Retraction HTTP/S-Expression Binding

Earlier drafts of the OWLlink specification have been published by the informal OWLlink working group at http://www.owllink.org.

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.


Table of Contents


1 Introduction

Strong evidence suggests that [OWL 2] will become an important standard for representing ontologies. According to the W3C, its purpose is to enable applications to meaningfully process information by means of reasoning. However, this requires not only a language standard for ontologies, but also a standard way to interact with components that supply reasoning or accompanying services. OWLlink adds this piece of ontology infrastructure by providing an extensible protocol for communication among OWL 2 aware systems intended to replace the outdated [DIG] protocol (cf. Appendix: Historical Notes).

Since syntax and semantic of the OWLlink language primitives are based on OWL 2, the effort to support the core protocol with respect to parsing ontology axioms is minimal. Consequently, OWLlink inherits all of its underlying language concepts such as punning and the OWL 2 notion of structural equivalence [OWL 2 Structural Specification]. It differs from ordinary ontology APIs, such as the Java-based OWL API, in that it is language-neutral and flexible in how to encode as well as transmit API calls and responses. OWLlink is designed to supports different transport mechanisms ranging from in-memory access over remote interface calls to Web service invocations. The default transport mechanism (so called binding) is XML over HTTP [OWLlink HTTP/XML Binding].

We introduce the structural specification of the OWLlink core using class diagrams expressed in the Unified Modeling Language (UML). This allows for a specification of the OWLlink primitives at a conceptual level decoupled from a concrete protocol and syntax.

2 Preliminaries

The OWLlink interface makes a number of assumptions:

The OWLlink specification does not address issues such as authentication, encryption, and compression. Yet some features might be transparently provided by the access protocol (e.g., [HTTP/1.1]) underlying a concrete OWLlink binding.

OWLlink relies on the [OWL 2 Specification] for the language used to express KB axioms. OWL 2 has also been specified using UML, so OWLlink simply reuses many UML classes provided by OWL 2. The UML notation used in this document is restricted to a very limited subset of UML class diagram notation. The names of abstract classes are written in italic. The names of all OWL 2 UML concepts are prefixed with owl. to emphasize that they are not defined in this specification.

Furthermore, OWLlink is in compliance with the [OWL 2 Conformance] conditions and OWLlink servers have to meet the respective tool conformance requirements. The only notable exception is, that the default language binding of OWLlink is based on the [OWL 2 XML Serialization] and that OWLlink servers do not necessarily have to accept the RDF/XML syntax of OWL 2. They could, of course, support RDF/XML syntax by offering a respective OWLlink language binding.

OWLlink inherits the notion of structural equivalence of OWL 2. An OWLlink server has to to accept sets containing duplicates of structurally equivalent axioms without raising an error, but is free to provide a warning in this case.

The datatypes string, boolean and int used within this specification are mapped to the [XML Schema Datatypes] xsd:boolean,xsd:string, and xsd:int datatypes.

OWLlink entities are identified using International Resource Identifiers (IRIs). OWLlink complies to the OWL 2 IRI abbreviation mechanism in that it supports the OWL 2 standard prefix names [OWL 2 Specification]. Client specific prefixes can be declared per KB only at creation time (cf. Figure 3).

3 Basic Protocol

OWLlink is a client-server protocol. It is specified in two parts: the first part defines the abstract protocol, and the second part defines the binding of the protocol into a concrete transport mechanism. While the abstract protocol is defined in this specification document, its binding to [HTTP/1.1] and [XML Schema] is given in an accompanying document [OWLlink HTTP/XML Binding].

This document uses UML class diagrams to specify the abstract protocol. Thereby all following diagrams depict both, the OWLlink request and their corresponding response message. In case multiple requests are bundled with different responses within one diagram, a dashed red line indicates which response belongs to which request.

3.1 Sessions and Messages

Before sending a request to an OWLlink server, a client must establish an OWLlink session to the server that abstracts the actual bidirectional communication channel between the client and the server. The actual implementation of a session provides primitives to transport requests and responses and is defined by the transport mechanism used to access an OWLlink server.

OWLlink servers are allowed to service several clients concurrently. However, interaction within one OWLlink session is not concurrent. An OWLlink session is assumed to transport requests and responses sequentially. Each request should be processed by the OWLlink server such that the results are the same as if the requests were processed sequentially in the order they were dispatched. Furthermore, the server must send the responses to the client in exactly the same order in which the requests arrived. OWLlink does not prescribe how concurrent requests issued through different OWLlink sessions are to be handled. Each response can be transmitted only through the OWLlink session through which the corresponding request was initiated.

An OWLlink session can be terminated by the client or the server. Furthermore, due to environmental circumstances (e.g., network problems or timeouts), an OWLlink session can be broken asynchronously. Regardless of the cause, in case a session has been closed the status of the server is no longer determined by the protocol. An OWLlink server can, but is not required to, implement a transaction mechanism for rolling back not completed requests.

Protocol Objects
Figure 1. Protocol Objects

The basic interaction pattern of OWLlink is that of request-response. The fundamental objects used in the protocol are presented in Figure 1.

Each request is paired with exactly one response. Depending on the transport mechanism, it might be inefficient to send individual requests to an OWLlink server at a time. Therefore, OWLlink allows to bundle requests into messages. As shown in Figure 1, a RequestMessage object encapsulates a list of Request objects, whereas a ResponseMessage object encapsulates a list of Response objects.

A request message may contain a mixture of arbitrary management, tell (see Section 4), and ask (see Section 5) requests. This allows, for example, to create self-containing test cases for OWLlink servers. For instance, one single request may include the creation of a KB (with a user given IRI) followed by a tell, an ask, more tells, and further asks.

Each request message must correspond to exactly one response message. The response message must contain the responses to all the requests from the request message, and all responses must be listed in the response in the order of the corresponding requests. Note that an OWLlink server is free to execute the requests in any way it wishes, as long as the requests are seemingly executed sequentially. For example, if a request to update the KB is followed by a query request, the responses to the query must take the updates into account.

3.2 Naming Schema

The identifier of OWLlink entities (requests, responses, and their nested parts) follow a specific naming schema:

3.3 Confirmation and Error Handling

Request primitives that address a specific KB are subclasses of the abstract KBRequest class and the corresponding confirmations are subclasses of the abstract KBResponse class. If a request has been processed successfully, the returned type of the response depends on the request. If a request does not produce any specific data, the OWLlink server still has to return a Confirmation response to the client. For example, if a request to successfully write axioms into a KB a confirmation response of type OK is returned. A Confirmation (or any sub-type thereof) may contain a warning. For example, an OWLlink server may accept sets containing duplicates of objects without raising a warning. However, it may be useful to warn the user if this has happened, as this may indicate a spelling or typographical mistake.

If a request cannot be executed the OWLlink server should return an Error response to the OWLlink client containing a message specifying the cause for failure. Three pre-defined error classes allow for distinguishing syntactic violations (SyntaxError) from semantic problems (SemanticError) or problems regarding the management of a KB (KBError). Furthermore, there are some common errors which are worth of coming with a specific error class. These are the UnsatisfiableKBError which is raised in response to a Realize command or any query asked to an unsatisfiable KB (these are all asks of Section 5 with the exception of those described in Section 5.2 and Section 5.3), the ProfileViolationError in case of a profile grammar violation with respect to the selected profile, and the NotSupportedDatatypeError when referring to an unsupported datatype.

If a server cannot process a request, it should attempt to recover gracefully, and process other pending requests as if the error did not happen. If, however, this recovery is not possible the server should close the OWLlink session after sending the Error response. The state of the server after such an action is not prescribed by this specification.

One single OWLlink request may consist of various elements (such as a tell with a set of OWL 2 axioms) which modify a KB. Therefore, OWLlink does not consider requests as atomic communication elements. For example, a request for adding axioms to a KB might fail after several axioms have been consumed. In such a case the OWLlink server is not required to roll back already processed axioms — instead, the behavior of the server is implementation-specific. Nevertheless, OWLlink server implementors are encouraged to ensure that requests which modify a KB are executed atomically.

3.4 Identification and Status

All OWLlink servers must support the GetDescription request, shown in Figure 2, to allow clients to discover their identity and introspect their capabilities. The response to this request is a Description, providing information about the server's current state, including: the name of the OWLlink server, its version, an optional identification message, the OWLlink protocol version, the currently managed public and named KBs (see Section 3.5), the supported OWLlink extensions (see Section 3.6), and a set of configurations. In this way, each OWLlink client can introspect the current status and the capabilities of an OWLlink server. The OWLlink protocol version as of this specification is "1.0" (major.minor).

OWLlink server management
Figure 2. Server Description

A configuration is either a property or a setting. While properties are read-only, settings can be set via Set to values of the associated types by a client for a specific KB (see Section 3.5). The Description of a server lists the set of available configurations identified by their unique key. Each configuration item is associated with its values and its type. Values are transported in string constants and the set of possible types is restricted to simple types (at least the types boolean and string have to be supported by any implementation), enumeration types and homogeneous lists of such types. Note that the settings given in a Description are the default values that hold for newly created KBs. The actual settings that hold for a KB can be retrieved via a Settings request (cf. Section 3.5). As settings can be modified per KB at any time via Set requests, the default settings reported in a Description might differ from the actual settings retrieved by Settings.

While OWLlink defines the general format of configurations, it does not provide specific details on available configurations — these will be defined on a per-server basis. However, the following configurations have to be supported by any server.

3.5 Knowledge Base Management

OWLlink servers can manage more than one KB simultaneously. Each KB is identified with a unique owl.FullIRI on creation. These IRIs provide a handle that identifies the particular KB at a server. Most OWLlink requests are derived from the KBRequest class, which requires a kb parameter identifying the KB to which the request applies. If a KB with the given owl.FullIRI cannot be found, the server should return a KBError object.

CreateKB
Figure 3. Knowledge Base Allocation

A new KB is allocated within the OWLlink server by sending a CreateKB request (cf. Figure 3). If the optional argument kb of type owl.FullIRI is given, the new KB is allocated with this IRI, otherwise a new (server-generated) IRI is used. On successful creation of the new KB, a KB object containing the IRI that identifies the allocated KB is returned. The possibility to pass an identifying IRI along with a CreateKB request, allows OWLlink KBs to stand alone — a situation that is useful, say for test suites and benchmarking. However, if the given IRI is already in use by another KB allocated before or the KB could not be allocated for some other reasons (e.g., a low memory condition), the response to the CreateKB request is a KBError. Freshly allocated KBs are initially empty, not containing any fact or axiom except the built-in OWL 2 entities of the associated profile. Note that the only way to produce an empty KB (without using non-core features like retraction) is through a CreateKB request. The optional name argument of a CreateKB request allows the association of a name with a KB on creation. Such KB names do not have to be unique and thus cannot be used to identify a certain KB. However, named KBs are published together with their identifying KB owl.FullIRI in the servers Description object and thus accessible to other clients.

The use of unique IRIs allows to sidestep from some of the issues related to multiple clients. If a client chooses not to share a KB IRI with another client (either directly or by making it public through passing a name on creation), then the client can assume that it is the only one interacting with that KB. This is not entirely the case, as a malicious client could choose to try sending messages with random IRIs to a running OWLlink server (there is a chance, however, that such a client could luckily hit an IRI which is in use, but this potential situation is unlikely enough not to be concerned with it).

Different clients of the same server, like KB browsers or explanation tools, however, may want to share KBs by sharing IRIs or making KBs public through naming — it is then the clients' responsibility to manage and coordinate this sharing.

OWLlink supports the abbreviation mechanism for IRIs of OWL 2 entities (cf. Section ‘2.4 IRIs’ [OWL 2 Specification]) by allowing to associate a set of prefix declarations to each KB. Such a declaration consists of a pair containing a prefix name (a possible empty string) and a string containing the corresponding prefix expansion. The set of prefix declarations of a KB must contain at most one such declaration per prefix name, and it must not declare a standard prefix name. Within abbreviated IRI elements all occurrences of prefix names that are followed by the : (U+3A) character are replaced with their prefix expansion string during parsing, dropping also the corresponding : (U+3A) character. The set of standard prefix names (cf. Table 2 [OWL 2 Specification]) is declared by default for every KB as well as OWLlink management communication. Note that the prefix mechanism is not relevant w.r.t. structural equivalence as prefix declarations are only used during parsing (to expand abbreviated IRIs into full IRIs) and serializing (to abbreviate full IRIs). Prefix declarations are scoped to the KB to which they are associated, thus prefix declarations are not imported nor have an effect on the importing of ontologies (cf. Sect. 3.7 of [OWL 2 Specification]).

The prefix declarations of a KB can be retrieved by sending a GetPrefixes request (cf. Figure 3). The Prefixes response returns a set of all prefix declarations defined for a given KB. This set has to contain at least the declarations of the OWL 2 standard prefixes.

GetSettings
Figure 4. Knowledge Base Settings

The actual settings of a KB can be retrieved by sending a GetSettings request (cf. Figure 4). The Settings response should cover all the Setting elements of the Description. Note that Setting elements of a Settings object might differ in the values from the ones of the Description, as the former reports the actual values while the latter reports the default values. The response to a successful Set request is OK indicating that the value of the corresponding setting has been set to the given value within the server. At any time, the value reported by a Settings object for a setting has to correspond to the value of the previous successful Set request for that setting, or, in case no such request was ever issued, the default value for that setting as reported in the Description object. Note that a server might at any time decide to refuse a Set request. For example, a server might support the change of certain settings only if the corresponding KB is still empty. In that case, or if the addressed setting is not supported or the value does conflict with the settings type annotation, it has to return a corresponding Error object without modifying the value of the setting.

CreateKB
Figure 5. Knowledge Base Configuration and Release

It is good practice for clients to release a KB once it is not in use any more, as this allows the OWLlink server to free the resources allocated for the KB. This can be done using the ReleaseKB request (see Figure 5), to which the server should respond on success with the OK response and otherwise with a KBError. Once a KB has been released, any further requests using its IRI result in a KBError until a new KB of this IRI has been established via CreateKB.

3.6 Extensions

Different reasoners support different languages as well as different reasoning facilities. To support these differences, OWLlink is extensible. Current candidates for extensions are:

An OWLlink extension consists of a set of documents,

All documents must be available on the Web, and their IRIs must adopt the given naming schema for bindings. For instance, the specification of the retraction extension can be found at http://www.w3.org/Submission/2010/SUBM-owllink-extension-retraction-20100701/retraction/ and its corresponding HTTP/XML binding is described at http://www.w3.org/Submission/2010/SUBM-owllink-extension-retraction-20100701/retraction-httpxml/ (whereas the XML schema for the latter is at http://www.w3.org/Submission/2010/SUBM-owllink-extension-retraction-20100701/retraction.xsd). An OWLlink server reports the set of extensions supported for the binding used by a GetDescription request as part of the resulting Description object (cf. Figure 2) by listing their IRIs without the binding part. For example, a server supporting the retraction extension via its HTTP/XML binding would refer to http://www.owllink.org/ext/retraction within the supported extensions section of the Description element requested via this binding.

OWLlink implementors are free to extend the set of supported OWLlink primitives. This can be simply done by providing adequate subclasses of Request and Response with appropriate parameters. Since RequestMessage and ResponseMessage objects contain lists of Request and Response objects, respectively, such proprietary extensions can readily be passed in messages.

The extension mechanism should not be used for either overloading core OWLlink statements with additional information or altering their semantics.

4 Tells

Figure 6 shows the primitives for adding content to a KB. Since OWLlink relies on the concept language of OWL 2 for expressing content, it basically refers to the OWL 2 axioms. More precisely, a Tell request adds a set of OWL 2 axioms to the specified KB and a LoadOntologies request adds all axioms contained in the ontology documents identified by the given IRIs as well as all imported ontologies. A LoadOntologies request can be associated with an ordered list of IRIMappings which allow for re-directing ontology IRIs (e.g. for caching). Each mapping entry consists of two sequences of characters, namely the matching and the mapping pattern. The IRI of an ontology to load is compared character-wise from left to right with the matching patterns in their given order. In case it matches the complete matching pattern the matched part of the IRI is replaced with the mapping pattern.

Considering the following ordered list of IRIMappings:

IRIMapping(<http://www.example.com/> <http://localhost/examples/>)
IRIMapping(<http://www.example.com/my> <file:///ontologies/examples2>)

Given the ontology IRI <http://www.example.com/myOnt>. According to the given mapping this IRI will be mapped to <http://localhost/examples/myOnt> because of a match with the matching part of the first IRI mapping. Note that the matching part of the second mapping would also match, but will not be applied. Even if the ontology document cannot be found at the mapped IRI no other mappings are tried.

If an ontology could not be loaded after the mapping has been applied once, e.g., because it could not be found, the server must respond with a KBError. In the case the ontology document is malformed or invalid a SyntacticError or SemanticError must be returned.

Analogous to the definition of an ontology in OWL 2 an OWLlink KB is defined by a set of unordered axioms without duplicates based on the OWL 2 structural equivalence. An OWLlink server must not return an error in case a structurally equivalent axiom is submitted a second time but is free to provide a warning. It should, however, keep only one copy of the structurally equivalent axiom. If a server states to ignore annotations it also has to take this into account when checking for structural equivalence, i.e. has to filter annotations at all levels of the tell language beforehand. If all axioms are successfully added to the KB, the server should respond with an OK response.

Structure of KB tells
Figure 6. Primitives for Adding Axioms to a KB

4.1 Reasoner Invocation

Requests for Reasoner Invocation
Figure 7. Requests for Reasoner Invocation

OWLlink does not require an explicit classification or realization request before querying. As regards any queries the server has to take care about computing inferences and decide when it is appropriate to, for example, classify or realize a KB. However, client applications might want to explicitly invoke common reasoning jobs in order to compute results in advance or for benchmarking purposes. To meet these requirements OWLlink offers two requests as shown in Figure 7, namely Classify for computing the entire class hierarchy as well as Realize for computing the direct types (cf. GetTypes in Figure 23) for all individuals of the KB.

5 Asks

The OWLlink core includes a set of general requests for retrieving information about KB entities as well as entailed facts. These so called basic asks cover very common queries. In the first place these are requests needed to be more aligned with OWL 2 or which have been missed by user of previous versions of this protocol (cf. [DIG 1.1 Experience]). More complex queries are delegated to query extensions such as the [OWLlink Query Extension]. Furthermore, syntactical information about previously transfered axioms can be retrieved by using the [OWLlink Extension Told Data Access] extension.

Asks referring nonexistent KB entities will be answered with an error.

5.1 Entailment Queries

In compliance with the notion of an OWL 2 entailment checker (Section '2.2.1 Entailment Checker' of [OWL 2 Conformance]) an OWLlink server must be able to check whether a KB entails an OWL 2 axiom. For this purpose OWLlink provides a general entailment request. In particular, IsEntailed checks whether an OWL 2 axiom (one of the axioms specified in Section '9 Axioms' of the [OWL 2 Structural Specification]) is entailed by the respective KB with respect to the underlying semantics.

There are some important entailments which impose additional constraints as given with the OWL 2 axioms, such as the direct subsumers of classes and properties or the direct types of individuals. In order to support these OWLlink provides the IsEntailedDirect request which is only applicable to the following OWL 2 axioms: SubClassOf, SubObjectPropertyOf, SubDataPropertyOf, and ClassAssertion. In addition, IsEntailedDirect requires the entities within these axioms to be atomic, that is of type owl.Entity.

Following the [OWL 2 Conformance] specification about OWL 2 tools this (and other following) entailment asks return either True, False, or Unknown. Within OWLlink this corresponds to two sub types of KBResponse, either a BooleanResponse (when True or False) or an Unknown as shown in Figure 8. Since an OWL 2 conformant entailment checker should not return Unknown the following figures of this section omit the latter (even if it is a legal response w.r.t. the OWLlink specification).

Potential responses to entailment asks
Figure 8. General KB entailment request and responses

Note that Annotations as well as Declarations carry no semantics and are therefore entailed by every KB.

5.2 Retrieving KB Entities

Each particular request depicted in Figure 9 returns a set of all corresponding named OWL 2 entities which are referenced within the KB. That is a possibly empty SetOfXXX consisting of owl.XXX where XXX is one of owl.Class, owl.ObjectProperty, owl.DataProperty, owl.Datatype, owl.Individual, or owl.AnnotationProperty. For instance, the SetOfDatatypes response consists of all user defined and referenced built-in datatypes which occur within the axioms of the KB. Note that the built-in entities of OWL 2 are only returned in case they are explicitly referenced from within an axiom. Semantically equivalent entities are not grouped or marked as such.

Basic asks for retrieving KB entities
Figure 9. Basic Asks for Retrieving KB Entities

In case an OWLlink server ignores annotation (cf. Section 3.4) axioms it must not return annotation properties as well as classes, properties, etc. which only occur in annotation axioms. Furthermore, if a server ignores declarations (cf. Section 3.4), all declared entities will not be part of the responses unless they are referenced elsewhere. On the other hand, when declarations are not ignored the responses have to account for declared entities in all responses.

5.3 Checking KB Status

Asks for querying KB status
Figure 10. Request for Checking KB Status

Figure 10 shows the KB status requests. IsKBSatisfiable returns true if the KB is consistent with respect to its underlying semantics (cf. Section ‘2.5 Inference Problems’ of the [OWL 2 Direct Semantics] and Section ‘4.3 Satisfaction, Consistency and Entailment’ of the [OWL 2 RDF-Based Semantics]).

IsKBConsistentlyDeclared returns true if the KB follows the notion of consistent declarations as given in the [OWL 2 Structural Specification]. Note that if a server ignores declarations the IsKBConsistentlyDeclared query is undefined and it has to respond with an error.

The GetKBLanguage query returns a string representation of the internal, reasoner-specific language fragment of the KB. Note that due to potential optimization techniques or other processing steps this fragment may be different to the pure syntactical language characterization as well as may change over time (e.g. after adding/retracting axioms or reasoning).

5.4 Queries about Classes and Properties

5.4.1 Querying Classes

Basic entailment asks with respect to classes, such as subsumption, equivalence, and disjointness between classes or class expressions, can be done via the IsEntailed request. In addition, there is a IsClassSatisfiable request as shown in Figure 11.

Asks refering to semantic relationships between classes
Figure 11. Checking for Class Satisfiablility

In terms of the [OWL 2 Direct Semantics] a class expression CE is satisfiable with respect to a KB if there exists a model I of the KB such that (CE)C is not empty.

The basic class queries GetSubClasses and GetSuperClasses of Figure 12 return the sub- resp. superclasses of a given class expression. The subclasses of an OWL class expression CE are the named class entities (class expressions of type owl.Class including the built-in entities owl:Thing and owl:Nothing) Ci for which (Ci)C(CE)C (resp. ⊃ for super-classes) in all models of the KB. Both queries return a possibly empty set of class synsets. These class synsets embrace those classes which are equivalent to each other.

In case of direct is set to true then these queries only return the direct sub- resp. superclasses with the further constraint that there is no distinct Ck with (Ck)C(CE)C and (Ci)C(Ck)C.

Queries to classes wrt. the subsumption realationship
Figure 12. Basic Queries w.r.t. Subsumption between Classes

To retrieve the disjoint classes of a given class expression CE there is the GetDisjointClasses query. Considering the direct semantics these are those classes Cj where (Cj)C(CE)C = ∅. Since by definition every class (satisfiable or not) is disjoint with owl:Nothing the answer at least contains owl:Nothing.

The equivalent classes of a OWL class expression can be retrieved with the help of the GetEquivalentClasses query of Figure 13. This query returns a possibly empty set of class names Ci (SetOfClasses response) which are equivalent to the given class expression CE (see left hand side of Fig. 13), that is (Ci)C = (CE)C for all i. In case the given argument is a named class, the answer obviously contains at least this class.

5.4.2 Retrieving the Class Hierarchy

Queries refering to the class hierarchy
Figure 13. Basic Queries Referring to Equivalent Classes and the Class Hierarchy

The complete class hierarchy, or a sub-hierarchy thereof, can be retrieved utilizing a single request, namely GetSubClassHierarchy (cf. Figure 13). This query returns all super-/subclasses pairs of the KB, whereas the first element consists of a super class (more precisely its synset) and the second of a set of direct subclass synsets. In case a super class has no direct satisfiable named subclasses other than owl:Nothing or other unsatisfiable classes, the whole super-/subclasses pair is omitted. This means that owl:Nothing will never appear in a super-/subclasses pair and is also not permitted as an argument. The reason behind this is to minimize the number of pairs to be transfered by ruling out the implicitly given subclass relationships to owl:Nothing. The latter as well as all other unsatisfiable classes are carried as one synset within each ClassHierarchy response containing at least owl:Nothing.

There is no order of class subclass pairs within the response. When providing a class name as argument to GetSubClassHierarchy a fraction of the hierarchy will be returned starting with the supplied class as root. As a consequence, there will be the same result set to a GetSubClassHierarchy request with no as well as with owl:Thing as argument. Therefore, when retrieving the initial hierarchy of a just created KB the response will contain exactly one unsatisfiable class (namely owl:Nothing) and no class-/subclass pair.

The following table shows some KB axioms together with their responses w.r.t. the GetSubClassHierarchy request (and no given argument). The notation for responses uses a square bracket "[]" for each ClassSubClassesPair, a curly bracket "{}" for each SubClassSynset and a round bracket "()" for each ClassSynset.

KB (OWL 2 functional syntax) GetSubClassHierarchy() response
unsatisfiableClasses pairs
(owl:Nothing)
SubClassOf(A owl:Thing) (owl:Nothing) [(owl:Thing) {(A)}]
SubClassOf(A owl:Thing)
SubClassOf(B A)
SubClassOf(D A)
(owl:Nothing) [(owl:Thing) {(A)}]   [(A) {(B) (D)}]
EquivalentClasses(A owl:Thing)
EquivalentClasses(C owl:Nothing)
SubClassOf(B owl:Thing)
(C owl:Nothing) [(A owl:Thing) {(B)}]

5.4.3 Querying Object Properties

Likewise to the class asks there is an analogous way for checking whether a KB entails that an object property is functional, symmetric, etc. with help of the IsEntailed request. Furthermore there is an request for checking whether an object property is satisfiable at all as shown in Figure 14.

Asks refering to ObjectProperties
Figure 14. Basic Asks Referring to Object Properties

Queries about retrieving sub- as well as super-object properties are given in Figure 15.

Queries to ObjectProperties
Figure 15. Basic Queries to Object Properties

The answers to these queries are object property synsets analogous to the corresponding sub resp. super class requests. Furthermore, likewise to the corresponding class queries these queries also have a direct flag in order to retrieve all or only the direct sub- resp. super-object properties. Note that these queries do rely on the hierarchy of property expressions which is organized within a directed acyclic graph (DAG) spun by the direct subsumptionship relation. However, these queries return only the atomic (named) object properties of this hierarchy (analogous to the class requests). For instance, a direct sub-object property request returns the closest node in the hierarchy that has an atomic property in it, in case a direct child node contains only inverses (cf. the example at the end of this section).

Asks refering to the ObjectProperties
Figure 16. Basic Asks Referring to Equivalent and Disjoint Object Properties

The request for retrieving equivalent object properties (GetEquivalentObjectProperties) is shown in Figure 16. The respective response is a set of object properties (SetOfObjectProperties response). The result set of the GetDisjointObjectProperties query in Figure 16 are synsets of object properties (ObjectPropertySynsets). Analogous to classes the response at least covers the owl:bottomObjectProperty per definition.

The object property hierarchy can be retrieved with GetSubObjectPropertyHierarchy (Figure 17). It is analogous to the corresponding class query and returns pairs consisting of object property synsets and their corresponding set of sub-object property synsets. In addition to these pairs the response also delivers the unsatisfiable object properties within one extra object property synset.

Asks refering to the ObjectProperty hierarchy
Figure 17. Query for Retrieving the Object Property Hierarchy.

The following table shows a GetSubObjectPropertyHierarchy request and some GetSubObjectProperties requests w.r.t a KB containing just two SubObjectPropertyOf axioms, together with the expected responses. The notation for responses uses a square bracket "[]" for each ObjectPropertySubObjectPropertiesPair, a curly bracket "{}" for each SubObjectPropertySynsets and a round bracket "()" for each ObjectPropertySynset.

KB (OWL 2 functional syntax)
SubObjectPropertyOf(r (ObjectInverseOf s))
SubObjectPropertyOf(ObjectInverseOf(s) t)
Request Response
GetSubObjectPropertyHierarchy(owl:topObjectProperty) unsatisfiableClasses pairs
(owl:bottomObjectProperty) [(owl:topObjectProperty) {(t) (s)}]   [(t) {(r)}]
GetSubObjectProperties(owl:topObjectProperty, direct=true) {(t) (s)}
GetSubObjectProperties(owl:topObjectProperty, direct=false) {(t) (r) (s) (owl:bottomObjectProperty)}
GetSubObjectProperties(owl:ObjectInverseOf(t), direct=true) {(s)}
GetSubObjectProperties(owl:ObjectInverseOf(t), direct=false) {(s) (owl:bottomObjectProperty)}

5.4.4 Querying Data Properties

Essentially the same queries as for object properties are provided for data properties (cf. Figure 18).

Asks refering to DataProperties
Figure 18. Basic Ask Referring to Data Properties

The queries for retrieving all as well as only direct sub- and super-data properties are depicted in Figure 19.

Queries to DataProperties
Figure 19. Basic Queries to Data Properties

Requests for querying data property relationships are given in Figure 20. The result set to GetEquivalentDataProperties return a set of equivalent data properties. GetDisjointDataProperties returns one or more data property synsets which are disjoint to the given one.

Asks refering to the DataProperties
Figure 20. Basic Asks Referring to Equivalent and Disjoint Data Properties.

Likewise to the object property hierarchy, GetSubDataPropertyHierachy (Figure 21) responds with pairs of super- and sub-data properties as well as one additional synset of unsatisfiable data properties.

Asks refering to the DataProperty hierarchy
Figure 21. Query for Retrieving the Data Property Hierarchy.

5.5 Queries about Facts

The semantics of the following queries about facts is that of so called grounded queries. Thus, an individual is part of an answer to a query about a class or property assertion if and only if the corresponding assertion about this individual is entailed by the KB (cf. Section ‘2.3.2 Query Answering Tool’ of the [OWL 2 Conformance]).

For instance, retrieving the fillers of an object property r with respect to an individual i (see GetObjectPropertyTargets in Figure 27) given a KB containing solely the axiom ClassAssertion(ObjectMinCardinality(1 r) i) will return the empty set since there is no individual in the KB which satisfies the query condition.

5.5.1 Queries about Individuals

GetTypes gets all classes of which an individual is an instance of as depicted in Figure 22. For an individual a it returns all synonym sets of named classes C where (a)I(C)C in all models of the KB. When setting the direct flag to true the query returns only the most specific class synonym sets of the previous answer, namely those where there is no Ck with (a)I(Ck)C where (C)C(Ck)C. The answer contains at least one named OWL 2 class (owl:Thing in the case of no classes).

The flattened variant GetFlattenedTypes rules out any information about class equivalence from the response by simply returning a set of classes.

Since any individual is an instance of owl:Thing this class is in the answer set of GetTypes as well as GetFlattenedTypes for every individual. Responses to these requests therefore have to return at least one class synset containing owl:Thing (for the sake of brevity OWLlink does not introduce a new response type for non empty set of class synsets for this case).

Asks about individuals
Figure 22. Basic Query w.r.t. Individual Instantiation

Figure 23 show the GetDifferentIndividuals query which answers with a set of synsets containing all those individuals bn for a given a with (a)I(bi)I where 1 ≤ in.

Asks about disjoint individuals
Figure 23. Retrieving Disjoint Individuals

The equivalent individuals to an individual are returned as result to the query GetSameIndividuals (Figure 24) which answers with a nonempty set of equivalent individuals to a, namely all bn with (a)I = (bi)I where 1 ≤ in (and at least the individual itself). This query as well as the flattened variant for retrieving disjoint individuals (GetFlattenedDifferentIndividuals) return a set of individuals.

Asks about equivalent individuals
Figure 24. Retrieving Equivalent Individuals

5.5.2 Queries about Properties related to Individuals

To retrieve the object properties originating from a source individual or pointing to a target individual GetObjectPropertiesOfSource and GetObjectPropertiesOfTarget are provided (Figure 25). They return a set of object property synsets. The object properties of a source individual a1 are those object properties OP where there exists an individual a2 such that ((a1)I, (a2)I)(OP)OP in all models of the KB (and vice versa for the corresponding filler individual). The query GetObjectPropertiesBetween returns all object properties which relate two given individuals.

The negative flag of those queries indicates whether this queries refer to the positive (default) or negative object property assertions. When set to true this flag refers to NegativeObjectPropertyAssertions which state that two entities are not related by a property. For instance, the result set of the GetObjectPropertiesOfSource query will then consist of all object properties OP where there exists an individual a2 such that ((a1)I, (a2)I)(OP)OP in all models of the KB.

Note that the owl:topObjectProperty relates any pair of individuals and has to be in the answer set of all requests of Figure 25 with the exception of the OWL 2 RL profile which does not support this predefined object property.

Asks about object properties which relate individuals
Figure 25. Querying Instantiated Object Properties between Individuals

In Figure 26 there are the corresponding data property queries from above (Figure 25) in order to retrieve data properties which relate individuals with literals.

Note that the topDataProperty relates any pair of individuals and literals and has to be in the answer set of all requests with the exception of the OWL 2 RL profile which does not support this predefined object property.

Asks about individuals
Figure 26. Querying Instantiated Data Properties

5.5.3 Queries about related Individuals and Instances

The queries GetObjectPropertyTargets and GetObjectPropertySources take an object property and an source resp. target individual and return all fillers resp. sources with respect to the property (Figure 27). The result consists of a set of individual synsets. Formally, given an individual a and an object property OPE the GetObjectPropertyTargets response consists of all individuals bn where ((a)I, (bk)I)OPEOP for 1 ≤ kn in all models of the KB (and vice versa for the corresponding source query). The negative flags refer to the kind of property assertion (either positive or negative).

Asks about individuals
Figure 27. Querying Targets/Sources of Instantiated Properties

GetInstances returns those individuals which are instances of a provided class expression, i.e. all a w.r.t. CE for which (a)I(CE)C. When setting its direct flag to true the result set excludes those individuals which are also instances of subclasses of the given class expresssion.

Asks about individuals
Figure 28. Querying Targetss/Sources of Instantiated Properties (flattened version of Fig. 27)

The queries about related individuals also come in a so called flattened variant as shown in Figure 28. Here, the result set contains exactly the same individuals as before but is made flat in terms of not grouping equivalent individuals anymore. This is especially useful when applying the unique name assumption (UNA) where different identifier always refer to different individuals.

5.5.4 Queries about Individuals Related to Literals

Likewise to the queries about related individuals there are queries with respect to individuals related to literals via data properties. Those queries allow the retrieval of the source individuals for a given data property and literal as well as the literal for a given individual and data property (Figure 29). Note that the negative flag, in contrast to the object property queries, is only allowed within GetDataPropertySources (it is simply unclear how to deal with the result of e.g. GetDataPropertyTargets[negative=true]( a:i a:r ) with FunctionalDataProperty( a:r ), DataPropertyRange( a:r xsd:float ) and DataPropertyAssertion( a:r a:i "+1"^^xsd:float )).

Asks about individuals
Figure 29. Querying Targets/Sources of Instantiated Data Properties

The former also comes with a flattened variant (see Figure 30) in order to trade semantic information (about equivalent individuals) for a smaller result message in case communication performance is of high importance to the client.

Asks about individuals
Figure 30. Querying Targets/Sources of Instantiated Data Properties (flattened version of Fig. 29)

6 Appendix: Table of Requests and Responses

Reasoner and KB Management
Request Response
GetDescription Description
CreateKB KB
GetPrefixes Prefixes
GetSettings Settings
Set OK
ReleaseKB OK
Tell OK
LoadOntologies OK
Classify OK
Realize OK
Entailment Queries, KB Entities, and KB Status
Request Response
IsEntailed BooleanResponse
IsEntailedDirect BooleanResponse
GetAllObjectProperties SetOfObjectProperties
GetAllIndividuals SetOfIndividuals
GetAllClasses SetOfClasses
GetAllAnnotationProperties SetOfAnnotationProperties
GetAllDatatypes SetOfDatatypes
GetAllDataProperties SetOfDataProperties
IsKBSatisfiable BooleanResponse
IsKBConsistentlyDeclared BooleanResponse
GetKBLanguage StringResponse
Queries about Classes and Properties
Request Response
IsClassSatisfiable BooleanResponse
GetDisjointClasses ClassSynsets
GetSubClasses SetOfClassSynsets
GetSuperClasses SetOfClassSynsets
GetEquivalentClasses SetOfClasses
GetSubClassHierarchy ClassHierarchy
IsObjectPropertySatisfiable BooleanResponse
GetSubObjectProperties SetOfObjectPropertySynsets
GetSuperObjectProperties SetOfObjectPropertySynsets
GetEquivalentObjectProperties SetOfObjectProperties
GetDisjointObjectProperties ObjectPropertySynsets
GetSubObjectPropertyHierarchy ObjectPropertyHierarchy
IsDataPropertySatisfiable BooleanResponse
GetSubDataProperties SetOfDataPropertySynsets
GetSuperDataProperties SetOfDataPropertySynsets
GetEquivalentDataProperties DataPropertySynonyms
GetDisjointDataProperties DataPropertySynsets
GetSubDataPropertyHierarchy DataPropertyHierarchy
Queries about Individuals
Request Response
GetTypes ClassSynsets
GetFlattenedTypes Classes
GetDifferentIndividuals SetOfIndividualSynsets
GetFlattenedDifferentIndividuals SetOfIndividuals
GetSameIndividuals IndividualSynonyms
GetObjectPropertiesOfSource SetOfObjectPropertySynsets
GetObjectPropertiesBetween SetOfObjectPropertySynsets
GetObjectPropertiesOfTarget SetOfObjectPropertySynsets
GetDataPropertiesOfSource SetOfDataPropertySynsets
GetDataPropertiesBetween SetOfDataPropertySynsets
GetDataPropertiesOfLiteral SetOfDataPropertySynsets
GetInstances SetOfIndividualSynsets
GetObjectPropertyTargets SetOfIndividualSynsets
GetObjectPropertySources SetOfIndividualSynsets
GetFlattenedInstances SetOfIndividuals
GetFlattenedObjectPropertyTargets SetOfIndividuals
GetFlattenedObjectPropertySources SetOfIndividuals
GetDataPropertyTargets SetOfLiterals
GetDataPropertySources SetOfIndividualSynsets
GetFlattenedDataPropertySources SetOfIndividuals

7 Appendix: Historical Notes

OWL is based on Description Logics (DLs). Successful attempts to standardize an interface for DL reasoning systems go back to the mid 90s with the [DL Knowledge Representation System Specification (KRSS)]. The KRSS proposal defined a Lisp-like syntax with corresponding semantic and some basic queries for a rather expressive DL. KRSS was adopted, at least in most parts, by the widely used DL systems at that time (most notably [FaCT] and [RACER]. In 1999, Bechhofer et al. defined a [CORBA-based interface] largely tailored towards FaCT utilizing XML syntax.

The DL Implementation Group (DIG), a group of researchers and developers associated with implementations of DL systems, defined DIG 1.0 [DIG 1.0] in 2002 with the intention to specify a common system independent interface also supporting assertional knowledge, reasoner identification and concrete domains. Furthermore, the goal was to align with actual DL language fragments, such as those underlying DAML+OIL, and to use XML over HTTP as transport mechanism. The shortly following version [DIG 1.1] of 2003 was quickly adopted by numerous reasoning engines, ontology editors and other applications. Despite its success there remained several shortcomings, such as limitations in the supported language fragment, a lack of elementary queries, and no mechanism to extend the protocol [DIG 1.1 Experience]. Most of the identified issues were fixed in the draft specification of [DIG 2.0], introduced in 2006 [DIG 2.0 OWLED'06], by adding the requested features and lifting the concept language to that of [OWL 2]. Finally, [DIG 2.0] has been renamed into OWLlink in 2008 [OWLlink OWLED'08] to reflect the important shift from its DL roots to the XML-based cousin OWL and the lack of backwards compatibility to DIG. This current specification [OWLlink OWLED'09] is aligned to OWL 2 as specified in the W3C recommendation as of October 2009.

8 Acknowledgments

This specification has been produced by the OWLlink Working Group under consideration of contributions from Matthew Horridge (University of Manchester), Peter F. Patel-Schneider (Bell Labs Research, Alcatel-Lucent), Dmitry Tsarkov (University of Manchester), Anni-Yasmin Turhan (TU Dresden), Timo Weithöner (Ulm University).


9 References

[OWL 2 Overview]
OWL 2 Web Ontology Language: Document Overview W3C OWL Working Group eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-overview-20091027/. Latest version available at http://www.w3.org/TR/owl2-overview/.
[HTTP/1.1]
Hypertext Transfer Protocol – HTTP/1.1, Request for Comments 2616 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee.
[XML Schema]
XML Schema Part 1: Structures Second Edition Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, eds. W3C Recommendation 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.
[Description Logics]
The Description Logic Handbook: Theory, Implementation, and Applications, second edition/cite> Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi, and Peter Patel-Schneider, eds. Cambridge University Press, 2007
[OWL 1 Overview]
OWL Web Ontology Language Overview Deborah L. McGuiness, Frank van Harmelen. W3C Recommendation 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/.
[OWL 2 Specification]
OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax Boris Motik, Peter F. Patel-Schneider, Bijan Parsia, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/. Latest version available at http://www.w3.org/TR/owl2-syntax/.
[OWL 2 XML Serialization]
OWL 2 Web Ontology Language: XML Serialization Boris Motik, Bijan Parsia, Peter F. Patel-Schneider, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/. Latest version available at http://www.w3.org/TR/owl2-xml-serialization/.
[XML Schema Datatypes]
XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes David Peterson, Shudi (Sandy) Gao, Ashok Malhotra, C. M. Sperberg-McQueen, Henry S. Thompson. W3C Proposed Recommendation 22 September 2009, http://www.w3.org/TR/xmlschema11-2/.
[OWL 2 Direct Semantics]
OWL 2 Web Ontology Language: Direct Semantics Boris Motik, Peter F. Patel-Schneider, Bernardo Cuenca Grau, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/. Latest version available at http://www.w3.org/TR/owl2-direct-semantics/.
[OWL 2 RDF-Based Semantics]
OWL 2 Web Ontology Language: RDF-Based Semantics Michael Schneider, editor. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-rdf-based-semantics-20091027/. Latest version available at http://www.w3.org/TR/owl2-rdf-based-semantics/.
[OWL 2 Profiles]
OWL 2 Web Ontology Language: Profiles Boris Motik, Bernardo Cuenca Grau, Ian Horrocks, Zhe Wu, Achille Fokoue, Carsten Lutz, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-profiles-20091027/. Latest version available at http://www.w3.org/TR/owl2-profiles/.
[OWL 2 Conformance]
OWL 2 Web Ontology Language: Conformance Michael Smith, Ian Horrocks, Markus Krötzsch, Birte Glimm, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-conformance-20091027/. Latest version available at http://www.w3.org/TR/owl2-conformance/.
[OWL API]
The OWL API Matthew Horridge, Sean Bechhofer, Olaf Noppens, June 2007, http://owlapi.sourceforge.net/
[OWLlink HTTP/XML Binding]
OWLlink: HTTP/XML Binding Document included in the present W3C Member Submission.
[OWLlink HTTP/Functional Binding]
OWLlink: HTTP/Functional Binding Document included in the present W3C Member Submission.
[OWLlink HTTP/S-Expression Binding]
OWLlink: HTTP/S-Expression Binding Document included in the present W3C Member Submission.
[OWLlink Extension Retraction]
OWLlink Extension: Retraction Document included in the present W3C Member Submission.
[OWLlink Extension Told Data Access]
OWLlink Extension: Told Data Access Thorsten Liebig. Working Group Draft, 1 October 2008, http://www.owllink.org/ext/told-access-20081001/. Latest version available at http://www.owllink.org/ext/told-access/.
[OWLlink Extension Query Interface]
DIG 2.0 Proposal for a Query Interface Alissa Kaplunova, Ralf Möller. DIG Working Group Draft, Jan 2007, http://www.sts.tu-harburg.de/~al.kaplunova/dig-query-interface.html.
[OWLlink Extension Concrete Domain Interface]
DIG 2.0 Proposal for a Concrete Domain Interface Alissa Kaplunova, Ralf Möller. DIG Working Group Draft, Sep 2006, http://www.sts.tu-harburg.de/~al.kaplunova/dig-cd-interface.html.
[OWLlink Extension Non-standard Inferences]
DIG 2.0 Proposal for Non-standard Inferences Anni-Yasmin Turhan, Yusri Bong. DIG Working Group Draft, Sep 2006, http://lat.inf.tu-dresden.de/~turhan/NSI.html.
[OWLlink Extension Explanation Extension]
DIG 2.0 Proposal for an Explanation Interface Boontawee Suntisrivaraporn. DIG Working Group Draft, Sep 2006, http://lat.inf.tu-dresden.de/~meng/dig-nsi-explanation.html.
[DL Knowledge Representation System Specification (KRSS)]
Description-Logic knowledge representation system specification from the KRSS group Peter Patel-Schneider, Bill Swartout. Working Draft, 1993.
[FaCT]
Using an expressive Description Logic: FaCT or fiction? Ian Horrocks. In Proceedings of the 6th International Conference on Principles of Knowledge Representation and Reasoning (KR'98), 636-647, 1998.
[RACER]
Description of the RACER system and its applications Volker Haarslev, Ralf Möller. In Proceedings of the 6th International Workshop on Description Logics (DL'01), 2001.
[CORBA-based interface]
A proposal for a Description Logic interface Sean Bechhofer, Ian Horrocks, Peter F. Patel-Schneider, Sergio Tessaris. In Proceedings of the 6th International Workshop on Description Logics (DL'99), 1999.
[DIG 1.0]
The DIG Description Logic Interface: DIG/1.0 Sean Bechhofer. Technical Report, Oct 2002.
[DIG 1.1]
The DIG Description Logic Interface: DIG/1.1 Sean Bechhofer. Technical Report, Feb 2003.
[DIG 1.1 Experience]
Implementation Experience with the DIG 1.1. Specification Ian Dickinson. Technical Report HPL-2004-85, Hewlett-Packard, 2004, http://www.hpl.hp.com/techreports/2004/HPL-2004-85.html.
[DIG 2.0 Document Index]
DIG 2.0: The DIG Description Logic Interface DIG Working Group Note September 2006, http://dig.cs.manchester.ac.uk/index.html.
[DIG 2.0 OWLED'06]
DIG2.0 – towards a flexible interface for Description Logic reasoners Anni-Yasmin Turhan, Sean Bechhofer, Alissa Kaplunova, Thorsten Liebig, Marko Luther, Ralf Möller, Olaf Noppens, Peter Patel-Schneider, Boontawee Suntisrivaraporn, and Timo Weithöner. In Proceedings of the OWL Experience and Directions Workshop at the ISWC'06, November 2006.
[OWLlink OWLED'08]
OWLlink: DIG for OWL 2 Thorsten Liebig, Marko Luther, Olaf Noppens, Mariano Rodriguez, Diego Calvanese, Michael Wessel, Ralf Möller, Matthew Horridge, Sean Bechhofer, Dmitry Tsarkov, and Evren Sirin. In Proceedings of the OWL Experience and Directions Workshop at the ISWC'08, November 2008.
[OWLlink OWLED'09]
The OWLlink Protocol Thorsten Liebig, Marko Luther, Olaf Noppens. In Proceedings of the OWL Experience and Directions Workshop at the ISWC'09, October 2009.