Introduction

OWLlink provides a declarative interface to OWL reasoners. It is intended to be a lightweight mechanism giving client applications access to reasoning functionality provided by a server. The OWLlink core defines primitives for handling and manipulation of OWL Knowledge Bases (KBs), such as asserting axioms, as well as primitives for asking questions about KB entities.

Early attempts to standardize an interface for Description Logic (DL) systems go back to the late 90s. At that time, most DL systems (e. g., FaCT [1] and RACER [2]) provided proprietary interfaces using a Lisp-like syntax more or less compliant with the KRSS syntax [3]. In 1999, Bechhofer et al. [4] defined a CORBA-based interface to FaCT using XML syntax, enlarging the scope to more expressive DLs than covered by the KRSS specification. However, both interfaces are more or less system-oriented and were quoted as being a handicap for application developers.

The initial DIG 1.0 specification of 2002 [5] was designed by the DL Implementation Group (DIG), a self-selecting assembly of researchers and developers associated with implementations of DL systems. Its intention was to overcome the limitations of the CORBA-FaCT interface, by adding support for assertional knowledge (not supported by FaCT at that time), reasoner identification and concrete domains, among others. Furthermore, the goal was to align with actual DL language fragments, such as those underlying DAML+OIL, and to provide an HTTP based interface for the client-server communication. The shortly following version DIG 1.1 of 2003 [6] 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 [7]. Most of the identified issues were fixed in the draft specification of DIG 2.0 [8] by adding the requested features and lifting the concept language to OWL 2 [9]. Finally, DIG 2.0 has now been renamed into OWLlink to reflect the important shift from its DL roots to the XML-based cousin OWL and the lack of backwards compatibility to DIG.

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 is reduced. Consequently, OWLlink inherits all of its underlying language concepts such as punning1 and the OWL 2 notion of structural equivalence. However, it does not support any parts of OWL 2 beyond the level of axioms. In particular, it does not support imports and the notion of an ontology. Client applications have to resolve any issues related to the handling of imports before passing a KB to an OWLlink server. Under this view, the OWLlink interface is by far more abstract in terms of implementation languages and internal representation models than frameworks that provide access to data structures representing OWL ontologies such as the Java specific OWL API [10]. Furthermore, the OWLlink specification does not address issues such as stateful connections, transactions, authentication, encryption, compression, concurrency, multiple clients and so on. Yet some features (such as authentication, encryption and compression) might be transparently provided by the access protocol (e. g., HTTP/1.1).

OWLlink is specified in two parts: the first part defines the abstract protocol, and the second part defines a binding of the protocol into a concrete transport mechanism. The abstract protocol is introduced in Sect. 2 and Sect. 3, its binding to HTTP/1.1 and XML Schema is given in Sect. 4. The full specification can be found online. 2

Basic Protocol

OWLlink is a client-server protocol that makes a number of assumptions.

-The connection to the server is stateless and clients are not identified.

-OWLlink does not provide any support for modularity of Knowledge Bases. 3-There is no explicit classification request. The server will decide when it is appropriate to, for example, compute the classification hierarchy of concepts.

The following definitions use a very limited subset of UML class diagram notation, reusing many UML classes provided by the OWL 2 specification [9]. The names of abstract classes (that is, the classes that are not intended to be instantiated) are written in italic. The names of all OWL 2 UML classes are prefixed with ox. to emphasize that they are not defined in the OWLlink specification.

Sessions and Messages

An OWLlink session abstracts the actual bidirectional communication channel between the client and the server. It provides primitives to transport requests and responses. The actual implementation of a session is defined by the transport mechanism used to access a OWLlink server. OWLlink servers are allowed to service several clients concurrently; however, interaction within one session is not concurrent. A session is assumed to transport requests and responses sequentially ordered. Each request should be processed by the server such that the results are the same as if the requests were processed sequentially in the order they were dispatched.

The basic interaction pattern is that of request-response. Each request is paired with exactly one response. Depending on the transport mechanism, it might be inefficient to send individual requests to a server separately. Therefore, OWLlink requests are bundled into messages. A RequestMessage object encapsulates a list of Request objects, whereas a ResponseMessage object encapsulates a list of Response objects (cf. Fig. 1).

Confirmation and Error Handling

Each request in OWLlink must be answered by a corresponding response. If a request has been processed successfully, the type of the response returned depends on the request and may contain additional data. If a request does not produce any specific data, the server should still return a Confirmation response (or subtype thereof) to the client. Any confirmation may carry a warning in terms of a string intended to be meaningful to a human user.

If a request fails for some reason, the server should return an Error response to the client containing a message specifying the cause for failure. Specific error classes are defined to report syntactic violations (SyntaxError), semantic problems (SemanticError) and issues regarding the management of a Knowledge Base (KBError). 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, after sending the Error response, the server should close the session.

Identification and Status

All OWLlink servers must support the GetDescription request, to allow clients to discover its identity and introspect its capabilities. The response to this request is a Description, providing information about the servers current state, A Configuration is either a Property or a Setting. While properties are read-only, settings can be adjusted per KB at any time via a Set request. The settings given in a Description indicate the servers defaults that hold for newly created KBs. The actual settings can be retrieved via GetSettings.

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 OWLlink server.

selectedProfile A configuration that names the default profile of the server in case of a Description response and the active profile in a Settings response. Its type restricts the possible values to the list of language fragments supported by the server. Any well-defined DL fragment might be referenced by name in this list, including, but not limited to, the ones defined by the OWL 2 Profiles [11] such as EL++, DL-Lite, OWL-R DL, etc.

ignoresAnnotations OWL 2 provides mechanisms for associating annotations with KB axioms and entities. If the management of annotations might incur unnecessary implementation and run-time overhead, this configuration allows to instruct an OWLlink server to ignore annotations.4 ignoresDeclarations If a server is instructed to ignore declarations via this configuration, all received declaration axioms are treated as not being send.

In case a server deals with declarations a declaration axiom is treated as all other axioms (e.g. being sensible to structural equivalence). uniqueNameAssumption A configuration specifying whether the server employs the Unique Name Assumption (UNA) such that different names always refer to different entities in the world. 5

Knowledge Base Management

Servers may manage several KBs simultaneously. Therefore, each KB is identified with a unique URI on creation. These URIs provide a handle that identifies the particular incarnation of the KB in the particular server. Most requests are derived from the KBRequest class, which requires a kb argument identifying the KB to which the request applies (cf. Fig. 1). If a KB with the given URI cannot be found, the server should return a KBError object.

A new KB is allocated within the server by sending a CreateKB request. If the optional URI argument kb is given, the new KB is allocated with this URI, otherwise a fresh (server-generated) URI is used. However, if the given URI 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. The optional name argument of a CreateKB request allows to associate 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 URI in the servers Description object to be accessible from multiple clients.

The use of unique URIs allows to sidestep some of the issues relating to multiple clients. If a client chooses not to share a KB URI with another client (either directly or by making it public through passing a name on creation), then the client can be sure that it is the only one interacting with that KB. 6Different clients of the same server, like KB browsers or explanation tools, however, may want to share KBs by sharing URIs or making KBs public through naming -it is then the clients' responsibility to manage and coordinate this sharing. The possibility to pass an identifying URI along with a CreateKB followed by a mixture of arbitrary tell and ask request allows OWLlink KBs to stand alone -a situation that is useful, say for test suites and benchmarking.

Extensions

Different reasoners support different language fragments and different reasoning facilities. To support these differences and future developments, OWLlink is extensible. Current candidates for extensions are:

Axiom Retraction Adds the ability to retract previously told axioms from KBs. Axiom retraction is sensitive to the rules of structural equivalence.7 Told Information Retrieval Provides access to previous told KB entities by returning requested portions of axioms -structurally exactly as given in previous tell messages. 8Ontology Based Data Access (OBDA) Extends OWLlink by the concepts of data source and mapping to support OBDA architectures facilitating the integration of data from existing data repositories.9

Other extensions are on the way such as a conjunctive query, a concrete domain interface, a non-standard inferences, and an explanation interface extension.

An extension consists of a set of documents specifying the additional messages, a structural specification providing sufficient information about their meaning, and a document per supported binding defining their syntax.

All documents must be available on the Web. A server reports the set of extensions supported for the binding used by a GetDescription request as part of the resulting Description object by listing their URIs without extension.

Tells & Asks

Tell Language

As mentioned before, OWLlink relies on the language primitives of OWL 2. With respect to the tell requests -those message parts which add axioms to a KBthis basically means that OWLlink refers to the various axioms about classes, properties or facts defined in Sect. 6 of the OWL 2 specification [9]. As depicted in Fig. 1 a tell request contains a set of one or more OWL 2 axioms and will be answered with a OK response when successfully processed by the server.

Basic Asks

The OWLlink core includes a set of general requests for retrieving information about the KB. These so called basic asks cover common queries with respect to the given and inferred axioms of the KB. They substantially extend the query interface of DIG 1.1 with requests needed to be more aligned with OWL 2 or which have been missed by DIG user. In order to provide an informal overview the following table lists all of them. Their semantic and a detailed description of their corresponding responses is given in the OWLlink structural specification.

Within this table "[O|D]

" abbreviates that this query exists in two flavors, either for Object-as well as for DataProperties. Furthermore the "XXX" in Is[O|D]PropertyXXX is a wild-card for the various characteristics a property can have.

Responses of type SetOfXXXSynset consist of zero or more synsets of an OWL 2 entity such as Individual, Object-or DataProperty, or OWLClass. Such a synset is a set of one or more elements whose members are all equivalent to each other, i. e. for which mutual equivalence is entailed from the axioms of the KB. In case this information about equivalence sets is not needed (e. g. due to UNA) there are so called flattened variants for those asks which deal with return sets consisting of individuals.

HTTP/XML Binding

The HTTP/XML binding of OWLlink uses HTTP as its underlying communication protocol for exchanging XML content between a reasoner and a client. Other bindings may utilize SOAP or a particular Remote Message Invocation protocol. Technically, within the HTTP/XML environment, the reasoner has to accept HTTP POST request and responds as appropriate according to the OWLlink specification. In order to alleviate the verbose nature of any XML-based protocol OWLlink servers should support the use of the standard compression technology for Content-Encoding of the HTTP/1.1 transport mechanism.

Sessions and Messages

An OWLlink session is mapped to an HTTP connection and is typically established upon sending the first request. HTTP servers are in general allowed to close the HTTP connection at their own discretion, which in effect terminates the OWLlink session. 10 In order to prevent this from happening, the client can include the keepAlive in the header of each HTTP request it sends.

XML Schema

The XML schema is obtained by a straightforward translation of the objects from the structural specification: in general, the names of XML elements correspond to the names of the corresponding UML classes. It relies on the OWL 2 XML serialization for the primitives of the ontology language, and is therefore fully compatibly with OWL. As a result, implementors of the XML binding can re-use their implementation of OWL 2 parsers to read the OWL 2 specific contents of the tell and ask primitives.

Each OWLlink request (i. e., management, tell and ask primitives) must be acknowledged by a corresponding OWLlink response that are pooled within a RequestMessage respectively a ResponseMessage. Following a straightforward translation of the OWLlink specification into an XML schema the content body of a HTTP message is either the root element RequestMessage or a ResponseMessage containing requests resp. responses as can be seen in Fig. 2

Discussion

Strong evidence suggests that OWL 2 will become an important standard for representing ontologies. According to the W3C its featured usage is to enable applications to meaningfully process information by means of reasoning. However, from the application's point of view this requires not only a language standard for ontologies but also a standard way to interact with components which supply reasoning or other services. OWLlink adds this latter piece of the ontology infrastructure by providing an extensible protocol for communication with OWL reasoning systems. The OWLlink protocol facilitates client applications to configure a reasoner, to transmit OWL 2 axioms, and to access reasoning services via a set of basic queries. Furthermore, OWLlink is flexible in that it allows to add any desired functionality by defining a corresponding extension.

The current OWLlink specification is still a draft and obviously cannot be finalized before the OWL 2 language specification has reached W3C recommendation status. In the meantime the OWLlink specification itself has to undergo a process where interface details (e. g. server descriptions or the basic asks) need to be reviewed by potential server and client developers as well as users. Therefore, anyone who feels addressed by this initiative is requested to join the discussion and to provide feedback to the OWLlink working group11 as well as to the developers of those OWL components they would like access via OWLlink.

In fact, the developers of the established and most widely used reasoning systems RacerPro, Pellet and FaCT++ attentively follow the development of OWLlink and some already have announced to support the protocol. 12 The developers of the QuOnto system are in the process of migrating their current OBDA extension for DIG 1.1 to the new OWLlink proposal (cf. Sect. 2.5). Various other developers of client applications, for example ontology editing and browsing tools such as the Protégé 4 or OntoTrack, also commited to adopt OWLlink. The same holds for the Java based OWL-API.

OWLlink provides a framework for accessing management and reasoning services around the forthcoming OWL 2. It is flexible to cope with future demands with respect to the underlying language as well as services. Beyond that it is designed on a structural level which enables many different bindings to concrete transport mechanisms. Besides the introduced XML/HTTP binding there are many other options. For instance there is a draft with respect to a binding aming at transporting OWL 2 functional prefix style syntax over HTTP (or a simple TCP socket connection). 13 The latter would provide a modern substitute for the outdated KRSS standard. Even an in-memory binding within one application, by mapping the OWLlink primitives to interfaces for instance, is a desired and sensible usage of OWLlink. In any case using OWLlink comes with the benefit of having a well-defined interface that allows to easily plug different OWL-aware components together.