The OWLlink interface provides an implementation-neutral mechanism for accessing OWL reasoner functionality. In contrast to its DL-oriented predecessor DIG, OWLlink relies on OWL 2 for the primitives of the modelling language, and is thus fully compatible with the forthcoming incarnation of OWL. The OWLlink core introduced in this document covers (i) basic reasoner management, (ii) assertion of axioms and (iii) elementary ask functionality. The OWLlink extension mechanism allows to easily add any required functionality in a controlled way to the core language. We introduce OWLlink by providing a structural speci cation and a concrete binding of the interface that de nes how OWLlink messages can be encoded in XML and sent over HTTP.
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 de nes 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 [
The initial DIG 1.0 speci cation of 2002 [
Since syntax and semantic of the OWLlink language primitives are based
on OWL 2, the e ort 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 speci c OWL API [
OWLlink is speci ed in two parts: the rst part de nes the abstract protocol, and the second part de nes 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 speci cation can be found online.2 2
OWLlink is a client-server protocol that makes a number of assumptions.
{ The connection to the server is stateless and clients are not identi ed.
{ OWLlink does not provide any support for modularity of Knowledge Bases.3
{ There is no explicit classi cation request. The server will decide when it is
appropriate to, for example, compute the classi cation hierarchy of concepts.
The following de nitions use a very limited subset of UML class diagram
notation, reusing many UML classes provided by the OWL 2 speci cation [
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 de ned 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 ine cient 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). 2.2
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 speci c data, the server should still return a Confirmation response (or subtype thereof) to the client. Any con rmation 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. Speci c error classes are de ned 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. 2.3
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, CreateKB kb: URI [0..1] name: String [0..1]
KBRequest
kb: URI
requests <<list>>
1..*
Request <<set>>
Tell axioms
1..* ox.Axiom
Ask IsClassSatisfiable class
1 ox.Description
ResponseMessage
responses <<list>>
1..*
Response
Confirmation warning: String [0..1]
Error error: String
KB kb: URI including: the name of the server, its version, an optional identi cation message, the protocol version, the currently managed public and named KBs (see Sect. 2.4), the supported extensions (see Sect. 2.5), and a set of con gurations.
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 de nes the general format of con gurations, it does not
provide speci c details on available con gurations { these will be de ned on a
per-server basis. However, the following con gurations have to be supported by
any OWLlink server.
selectedPro le A con guration that names the default pro le of the server
in case of a Description response and the active pro le in a Settings
response. Its type restricts the possible values to the list of language fragments
supported by the server. Any well-de ned DL fragment might be referenced
by name in this list, including, but not limited to, the ones de ned by the
OWL 2 Pro les [
Servers may manage several KBs simultaneously. Therefore, each KB is identi ed with a unique URI on creation. These URIs provide a handle that identi es 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.6
Di erent 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.
4 A server con gured this way should still accept annotations.
5 OWL does not make the UNA [
Di erent reasoners support di erent language fragments and di erent reasoning facilities. To support these di erences 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.8
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 speci cation providing su cient information about their meaning, and a document per supported binding de ning 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. 3 3.1
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 KB {
this basically means that OWLlink refers to the various axioms about classes,
properties or facts de ned in Sect. 6 of the OWL 2 speci cation [
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 speci cation. 7 http://www.owllink.org/ext/retraction-20081001/ 8 http://www.owllink.org/ext/told-access-20081001/ 9 http://obda.inf.unibz.it/owllink/obda-20081001/ s GetAllClasses ite GetAllObjectProperties i tn GetAllDataProperties E GetAllAnnotationProperties B K GetAllIndividuals
GetAllDatatypes s IsKBSatisfiable tau IsKBStructurallyConsistent tS GetKBLanguage
SetOfObjectProperties SetOfDataProperties SetOfAnnotationProperties SetOfIndividuals SetOfDatatypes
BooleanResponse
StringResponse IsClassSatisfiable BooleanResponse IsClassSubsumedBy BooleanResponse AreClassesDisjoint BooleanResponse AreClassesEquivalent BooleanResponse GetSubClasses SetOfClassSynsets GetSuperClasses SetOfClassSynsets GetEquivalentClasses SetOfClasses
GetSubClassHierarchy ClassHierarchy a Are[O|D]PropertiesEquivalent BooleanResponse ehm Is[O|D]PropertySatisfiable BooleanResponse cS Are[O|D]PropertiesDisjoint BooleanResponse
Is[O|D]PropertySubsumedBy BooleanResponse Is[O|D]PropertyXXX BooleanResponse GetUnsatisfiable[O|D]Properties SetOf[O|D]Properties GetDisjoint[O|D]Properties SetOf[O|D]PropertySynsets GetSub[O|D]Properties SetOf[O|D]PropertySynsets GetSuper[O|D]Properties SetOf[O|D]PropertySynsets GetEquivalent[O|D]Properties SetOf[O|D]Properties GetSub[O|D]PropertyHierarchy [O|D]PropertyHierarchy AreIndividualsEquivalent BooleanResponse AreIndividualsDisjoint BooleanResponse IsInstanceOf BooleanResponse GetTypes SetOfClassSynsets GetFlattenTypes SetOfClasses GetEquivalentIndividuals SetOfIndividuals GetDisjointIndividuals SetOfIndividualSynsets GetFlattenDisjointIndividuals SetOfIndividuals Get[O|D]PropertiesOfSource SetOf[O|D]PropertySynsets
GetObjectPropertiesOfFiller SetOfObjectPropertySynsets tsc GetDataPropertiesOfConstant SetOfDataPropertySynsets aF Get[O|D]PropertiesBetween SetOf[O|D]PropertySynsets GetInstances SetOfIndividualSynsets GetObjectPropertyFillers SetOfIndividualSynsets GetDataPropertyFillers SetOfConstants Get[O|D]PropertySources SetOfIndividualSynsets GetFlattenInstances SetOfIndividuals GetFlattenObjectPropertyFillers SetOfIndividuals GetFlatten[O|D]PropertySources SetOfIndividuals AreIndividualsRelated BooleanResponse
IsIndividualRelatedWithConstant BooleanResponse Within this table \[O|D]" abbreviates that this query exists in two avors, 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 attened variants for those asks which deal with return sets consisting of individuals. 4
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 speci cation. 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. 4.1
An OWLlink session is mapped to an HTTP connection and is typically established upon sending the rst request. HTTP servers are in general allowed to close the HTTP connection at their own discretion, which in e ect 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. 4.2
The XML schema is obtained by a straightforward translation of the objects from the structural speci cation: 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 speci c 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 10 Note that closing an OWLlink session does not imply the release of any KB. a RequestMessage respectively a ResponseMessage. Following a straightforward translation of the OWLlink speci cation 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. Some more detailed examples are given in Appendix A.
<owllink:RequestMessage> [request #1] [request #2] [ ... ] [request #n] </owllink:RequestMessage> <owllink:ResponseMessage> [response #1] [response #2] [ ... ] [response #n] </owllink:ResponseMessage> 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 congure a reasoner, to transmit OWL 2 axioms, and to access reasoning services via a set of basic queries. Furthermore, OWLlink is exible in that it allows to add any desired functionality by de ning a corresponding extension.
The current OWLlink speci cation is still a draft and obviously cannot be nalized before the OWL 2 language speci cation has reached W3C recommendation status. In the meantime the OWLlink speci cation 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 11 There is a public discussion forum at http://www.owllink.org/forum/ 12 Racer System will release an OWLlink compatible version of RacerPro shortly after this OWLED'08.
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 Protege 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 exible 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 di erent 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 pre x 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 bene t of having a well-de ned interface that allows to easily plug di erent OWL-aware components together. 13 http://www.owllink.org/owllink-httpsexpr-20081001/
A sample con guration request which is typically send at the initialization phase to introspect the OWLlink server capabilities: <RequestMessage xmlns="http://www.owllink.org/owllink-xml"> <GetDescription/> </RequestMessage> A corresponding reasoner response with information about the o ered OWLlink protocol version, reasoner version as well as o ered options and settings followed by a list of supported extensions and public KBs: The following is an example of a request (and its response) containing a \testsuite" or \benchmark-style" OWLlink message starting with the creation of a KB which is followed by a mixture of tells and asks: <!DOCTYPE ResponseMessage [ <!ENTITY owl "http://www.w3.org/2002/07/owl#"> ]> <RequestMessage xmlns="http://www.owllink.org/owllink-xml" xmlns:ol="http://www.owllink.org/owllink-xml" xmlns:ox="http://www.w3.org/ns/owl2-xml#"> <!-- KB management --> <!-- Some asks --> <CreateKB ol:kb="KB_1"/> <GetAllClasses ol:kb="KB_1"/> <CreateKB ol:kb="KB_2" <GetEquivalentClasses ol:kb="KB_1"> ol:name="My KB 2"/> <ox:OWLClass ox:URI="D"/> <!-- Some tells in KB_1--> </GetEquivalentClasses> <Tell ol:kb="KB_1"> <IsClassSubsumedBy ol:kb="KB_1"> <ox:SubClassOf> <ox:OWLClass ox:URI="&owl;Thing"/> <ox:OWLClass ox:URI="B"/> <ox:OWLClass ox:URI="&owl;Nothing"/> <ox:OWLClass ox:URI="A"/> </IsClassSubsumedBy> </ox:SubClassOf> <GetSubClasses ol:kb="KB_1"> <ox:SubClassOf> <ox:OWLClass ox:URI="C"/> <ox:OWLClass ox:URI="C"/> </GetSubClasses> <ox:OWLClass ox:URI="A"/> <!--Some tells in another KB --> </ox:SubClassOf> <Tell ol:kb="KB_2"> <ox:EquivalentClasses> <ox:SubClassOf> <ox:OWLClass ox:URI="D"/> <ox:OWLClass ox:URI="A"/> <ox:OWLClass ox:URI="E"/> <ox:OWLClass ox:URI="B"/> </ox:EquivalentClasses> </ox:SubClassOf> <ox:ClassAssertion> </Tell> <ox:OWLClass ox:URI="A"/> <!-- KB management --> <ox:Individual ox:URI="iA"/> <ReleaseKB ol:kb="KB_1"/> </ox:ClassAssertion> <!-- One more ask --> </Tell> <GetAllClasses ol:kb="KB_1"/> </RequestMessage> <!DOCTYPE ResponseMessage [ <!ENTITY owl "http://www.w3.org/2002/07/owl#"> ]> <ResponseMessage xmlns="http://www.owllink.org/owllink-xml" xmlns:ol="http://www.owllink.org/owllink-xml" xmlns:ox="http://www.w3.org/ns/owl2-xml#"> <!-- KB management --> </SetOfClasses> <KB ol:kb="KB_1"/> <BooleanResponse ol:result="false"/> <KB ol:kb="KB_2"/> <SetOfClassSynsets> <!-- tell --> <ClassSynset> <OK/> <ox:OWLClass ox:URI="&owl;Nothing"/> <!-- ask --> </ClassSynset> <SetOfClasses> </SetOfClassSynsets> <ox:OWLClass ox:URI="A"/> <!--Some tells in another KB --> <ox:OWLClass ox:URI="B"/> <OK/> <ox:OWLClass ox:URI="C"/> <!-- KB management --> <ox:OWLClass ox:URI="D"/> <OK/> <ox:OWLClass ox:URI="E"/> <!-- One more ask --> </SetOfClasses> <KBError errorMessage= <SetOfClasses> "KB KB_1 does not exist!"/> <ox:OWLClass ox:URI="E"/> </ResponseMessage>