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].
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:
- OWLlink:
Structural Specification (this document)
- OWLlink: HTTP/XML
Binding
- OWLlink:
HTTP/Functional Binding
- OWLlink:
HTTP/S-Expression Binding
- OWLlink Extension:
Retraction
- OWLlink
Extension: Retraction HTTP/XML Binding
-
OWLlink Extension: Retraction HTTP/Functional
Binding
-
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:
- An OWLlink Knowledge Base (KB) is a collection of OWL 2 axioms
and has to satisfy the conditions of OWL 2 ontologies as stated in
Section
‘3 Ontologies’ of the [OWL 2 Structural
Specification] with the exception that an OWLlink KB has
neither an ontology IRI nor a version IRI, but is identified by a
KB full IRI.
- The connection to the server is effectively stateless and
clients are not identified. Multiple client connections are
possible but no guarantees are made as to the semantics in the case
of simultaneous access.
- There is no explicit classification request needed before
querying. The server will take care of computing inferences when
required.
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.
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 defined by its type, a subclass of the
Request class, and the (possibly empty)
set of parameters. To call a service of an OWLlink server, a client
constructs a request of the appropriate type and sends it to the
server.
- After receiving a request and processing it, an OWLlink server
constructs an appropriate response object and sends it to the
client. Depending on the type of the request, the server has to
select the appropriate subclass of the Response class.
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:
- Entities are unambiguous with respect to their content as well
as the context in which they occur. For instance the (top-level) ClassSynsets response cannot become a part of another
response even if that part refers to the same content (therefore
called SubClassSynsets within the
GetSubClassHierarchy request).
- Responses and their nested parts which potentially return more
than one entity use a name in plural (e.g. IndividualSynonyms)
- Ask requests whose responses return OWL 2 entities or
structures containing such entities carry a "Get" prefix (e.g. GetAllClasses)
- Ask requests which are of validation kind of type (i.e. which
return a boolean value) have an "Is"
prefix (e.g. IsClassSatisfiable)
- Responses or nested parts thereof which group equivalent
entities of type class, object- or dataproperty carry a
"Synset" suffix (e.g. DataPropertySynset)
- Responses which potentially return zero or more results start
with an "SetOf" (e.g. SetOfClasses)
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).
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.
- 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 supported
language fragments. Any well-defined DL fragment (e.g., 'ALC', as
defined by the widely used DL naming scheme [Description Logics], 'OWL DL'
or 'OWL Lite' as the OWL 1 sublanguages [OWL 1 Overview], or 'OWL 2 DL', as
one of the OWL 2 named profiles [OWL 2 Profiles]) might be
referenced in this list.
- appliedSemantics
A configuration that names the semantics that is applied to
evaluate requests w.r.t. the selected profile. Its type
OneOf restricts the possible values to
the list of supported semantics. Any well-defined semantic (e.g.,
'direct' or 'RDF-based' as one of the OWL 2 semantics
[OWL 2 Overview])
might be referenced here.
- supportedDatatypes
A property of type List that lists the
datatypes supported by the server by referencing their IRI.
- abbreviatesIRIs
A configuration of type boolean
specifying whether the server generates abbreviated IRIs for OWL 2
literals in KBResponse elements w.r.t.
the IRI prefix abbreviations defined for the addressed KB (cf.
Section 3.5). Note that
even if this flag is not set, the server should still accept prefix
names in KBRequests and expands them to
the full IRIs as associated by the KBs prefix declarations.
- ignoresAnnotations
A configuration of type boolean
specifying whether the server supports annotations. OWL 2 provides
mechanisms for associating annotations with KB axioms and IRIs. If
the management of annotations might incur unnecessary
implementation and run-time overhead, this configures an OWLlink
server to ignore annotations by setting the ignoresAnnotations flag. Note that an server
configured this way should still accept annotations in the requests
— that is, it should not raise an error if a
request contains annotations, but should simply ignore them.
Furthermore, it should still employ the notion of structural
equivalence of OWL 2, with the provision that annotations are
not taken into account when comparing objects.
- ignoresDeclarations
A configuration of type boolean
specifying the servers behavior regarding OWL 2 declarations. If a
server states to ignore declarations all received declaration
axioms are treated as not having been send. In the case where a
server deals with declarations, a declaration axiom is treated as
are all other axioms (e.g., respected by structural
equivalence, etc.). A declaration axiom has a consequence in
that it will introduce an entity to a KB. For instance, when
declaring a class this class will appear in the answer set of the
GetAllClasses (cf. Figure 9) request unless all occurrences of the
class (including the declaration) have been explicitly retracted
from the KB.
- uniqueNameAssumption
A configuration of type boolean
specifying whether the server employes the Unique Name Assumption
(UNA) [Description
Logics] such that different names always refer to
different entities in the world. Note that OWL does not make the
UNA, but provides explicit constructs to express that two names
denote distinct entities [OWL 2 Specification]. Still,
an client might choose to enable the UNA in cases where the
reasoning performance is of utmost importance.
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.
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.
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.
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,
- a structural specification document providing sufficient
information about the meaning of the messages in the extension for
correct implementations to be built,
- a document per supported binding defining the syntax of the
messages in the extension.
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/submissions/2010/SUBM-owllink-extension-retraction-20100701/retraction/
and its corresponding HTTP/XML binding is described at http://www.w3.org/submissions/2010/SUBM-owllink-extension-retraction-20100701/retraction-httpxml/
(whereas the XML schema for the latter is at http://www.w3.org/submissions/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.
Figure 6. Primitives for Adding Axioms
to a KB
4.1 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).
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.
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
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.
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.
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
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.
Figure 14. Basic Asks Referring to
Object Properties
Queries about retrieving sub- as well as super-object properties
are given in Figure 15.
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).
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.
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).
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.
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.
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.
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).
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 ≤ i ≤n.
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 ≤ i ≤
n (and at least the individual itself). This query as well
as the flattened variant for retrieving disjoint individuals
(GetFlattenedDifferentIndividuals) return
a set of 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.
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.
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 ≤ k ≤ n 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).
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.
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
)).
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.
Figure 30. Querying Targets/Sources of
Instantiated Data Properties (flattened version of Fig. 29)
6 Appendix: Table of Requests and
Responses
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.
- 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.