Figure 1. Protocol Objects
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].
The OWLlink Working Group seeks public feedback on these Working Drafts. Please send your comments to public-comments@owllink.org or post to the public discussion forum at http://www.owllink.org/forum/.
Contents |
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.
The OWLlink interface makes a number of assumptions:
The OWLlink specification does not address issues such as authentication, encryption, and compression. Yet some features might be transparently provided by the access protocol (e.g., [HTTP/1.1]) underlying a concrete OWLlink binding.
OWLlink relies on the [OWL 2 Specification] for the language used to express KB axioms. OWL 2 has also been specified using UML, so OWLlink simply reuses many UML classes provided by OWL 2. The UML notation used in this document is restricted to a very limited subset of UML class diagram notation. The names of abstract classes are written in italic. The names of all OWL 2 UML concepts are prefixed with owl. to emphasize that they are not defined in this specification.
Furthermore, OWLlink is in compliance with the [OWL 2 Conformance] conditions and OWLlink servers have to meet the respective tool conformance requirements. The only notable exception is, that the default language binding of OWLlink is based on the [OWL 2 XML Serialization] and that OWLlink servers do not necessarily have to accept the RDF/XML syntax of OWL 2. They could, of course, support RDF/XML syntax by offering a respective OWLlink language binding.
OWLlink inherits the notion of structural equivalence of OWL 2. An OWLlink server has to to accept sets containing duplicates of structurally equivalent axioms without raising an error, but is free to provide a warning in this case.
The datatypes string, boolean and int used within this specification are mapped to the [XML Schema Datatypes] xsd:boolean,xsd:string, and xsd:int datatypes.
OWLlink entities are identified using International Resource Identifiers (IRIs). OWLlink complies to the OWL 2 IRI abbreviation mechanism in that it supports the OWL 2 standard prefix names [OWL 2 Specification]. Client specific prefixes can be declared per KB only at creation time (cf. Figure 3).
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.
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 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.
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 (e.g., because the selectedProfile as defined in the next section does not support a certain construct), the OWLlink server should return an Error response to the OWLlink client containing a message specifying the cause for failure. Specific error classes are defined to report syntactic violations (SyntaxError), semantic problems (SemanticError) and problems regarding the management of a KB (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 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.
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.4), the supported OWLlink extensions (see Section 3.5), 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.4). 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.4). 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.
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 pairs build of a prefix name (a possible empty string followed by the : (U+3A) character) and a corresponding string (prefix expansion). The set of prefix declarations of a KB must contain at most on such declaration per prefix name, and it must not declare a standard prefix name. Within all abbreviated IRI's all prefixes are replaced with their prefix expansion string during parsing. 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]).
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.
Different reasoners support different languages as well as different reasoning facilities. To support these differences, OWLlink is extensible. Current candidates for extensions are:
An OWLlink extension consists of a set of documents,
All documents must be available on the Web, and their IRIs must adopt the given naming schema for bindings. For instance, the specification of the retraction extension can be found at http://www.owllink.org/ext/retraction/ and its corresponding HTTP/XML binding is described at http://www.owllink.org/ext/retraction-httpxml/ (whereas the XML schema for the latter is at http://www.owllink.org/ext/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.
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
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.
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.
In compliance with the [OWL 2 Conformance] specification about OWL 2 tools all 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 the OWL 2 conformant entailment checker for the given language fragments 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. Responses to entailment asks
Each particular request depicted in Figure 9 returns a set of all corresponding named OWL 2 entities other than the OWL 2 built-in ones of the referenced 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. Semantically equivalent entities are not grouped or marked as such. The SetOfDatatypes response consists of all user defined datatypes which are actually referenced within the axioms of the KB.
Figure 9. Basic Asks for Retrieving KB Entities
In case an OWLlink server ignores annotation (cf. Section 3.3) 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.3), 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.
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]).
IsKBDeclaredConsistent 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 IsKBDeclaredConsistent 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).
The basic asks of Figure 11 about one or more classes all return a boolean value and cover requests such as class subsumption, class satisfiability, class equivalence, and class disjointness.
Figure 11. Basic Asks Referring to Classes
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. Furthermore, a set of n class expressions CEn is said to be equivalent to each other with respect to the KB if (CEi)C = (CEj)C for all 1 ≤ i, j ≤ n in every model I of the KB. In contrast such a set of class expressions are pair-wise disjoint if (CEi)C ∩ (CEj)C = ∅ for all 1 ≤ i, j ≤ n with i ≠ j in every model of the KB. Eventually, a class expression CEi is subsumed by an expression CEj if (CEi)C ⊆ (CEj)C in all models of the KB.
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) Ci for which (Ci)C ⊂ (CE)C (resp. ⊃ for super-classes) in all models of the KB. Both queries return a set of class synonym sets. The synonym sets embrace those classes which are equivalent to each other.
Note that the built-in class owl:Nothing is treated differently within these and all following class hierarchy requests, whereas owl:Thing is considered as any other named class and will therefore appear within at least one ClassSynset of any GetSuperClasses responses. In contrast, for the sake of small answers, owl:Nothing is eliminated from any response unless there is at least one named unsatisfiable class. In other words there will be no ClassSynset only containing owl:Nothing in any response. The GetSubClasses request, therefore, will respond with an empty SetOfClassSynsets either when asked for one of the leaves of the hierarchy, or when asked for owl:Nothing. The GetSuperClasses request will return an empty SetOfClassSynsets only when asked for owl:Thing.
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 = ∅. Note that since we rule out owl:Nothing (unless one unsatisfiable class) from the answer there might be an empty SetOfClassSynsets response even if any class is disjoint with owl:Nothing by definition.
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 nonempty 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.
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. The second element of such a pair is an empty set in case the super class has no unsatisfiable direct subclasses other than owl:Nothing (cf. sub/super class retrieval above). This means that owl:Nothing will only appear in a class hierarchy response in case of at least one unsatisfiable class or when provided as 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.
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 class subclass pair, whereas the first element is a synset containing owl:Thing and the second element consists of an empty set of subclass synsets.
The following table shows some KB axioms together with their responses w.r.t. the GetSubClassHierarchy request. The notation for responses uses a square bracket "[]" for each ClassSubClassesPair, a curly bracket "{}" for each SetOfClassSynset and a round bracket "()" for each ClassSynset.
| KB (OWL 2 functional syntax) | GetSubClassHierarchy() response |
|---|---|
| ∅ | [(owl:Thing) {}] |
| SubClassOf(A owl:Thing) | [(owl:Thing) {(A)}] |
| SubClassOf(A owl:Thing) SubClassOf(B A) SubClassOf(D A) |
[(owl:Thing) {(A)}] [(A) {(B) (D)}] |
| EquivalentClasses(A owl:Thing) EquivalentClasses(C owl:Nothing) SubClassOf(B owl:Thing) |
[(A owl:Thing) {(B)}] [(B) {(C owl:Nothing)}] |
Likewise to the class asks above there are analog asks about object properties as shown in Figure 14.
Figure 14. Basic Asks Referring to Object Properties
Furthermore, the IsObjectPropertyXXX checks for the various characteristics an object property can have. Here XXX can be one of Functional, InverseFunctional, Reflexive, Irreflexive, Symmetric, Asymmetric, or Transitive.
Figure 15. Basic Queries to Object Properties
Queries about sub- as well as super-object properties are given in Figure 15. The answers to these queries are sets of object property synsets. In correspondence with the class requests these asks eliminate the built-in owl:bottomObjectProperty unless there is at least one unsatisfiable object property. 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.
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 is a set of object property synsets (SetOfObjectPropertySynsets). Analogous to classes this might be an empty set of synsets since the owl:bottomObjectProperty is handled likewise to owl:Nothing for classes.
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.
Figure 17. Query for Retrieving the Object
Property Hierarchy.
Essentially the same queries as for object properties are provided for data properties. There is one exception with respect to the characteristics of data properties which are limited to IsDataPropertyFunctional as can be seen in Figure 18.
Figure 18. Basic Asks 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 other data properties. GetDisjointDataProperties returns a set of 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.
Figure 21. Query for Retrieving the Data
Property Hierarchy.
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 29) 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.
AreIndividualsEquivalent respectively AreIndividualsDisjoint of Figure 22 return true in case a set of provided individuals are all the same or all different from each other with respect to the underlying semantics. More precisely, under the direct semantics given a set of n individuals ai AreIndividualsEquivalent returns true if (ai)I = (aj)I with 1 ≤ i, j ≤ n for every model of the KB. The contrary case (AreIndividualsDisjoint) returns true if (ai)I ≠ (aj)I with 1 ≤ i, j ≤ n and i ≠ j. In case an OWLlink server has the UNA enabled AreIndividualsEquivalent always returns false and AreIndividualsDisjoint always true when asked with different identifiers.
Whether an individual is an instance of a class expression can be checked with help of IsInstanceOf. For an individual a and a class expression CE this query returns true in case (a)I ∈ (CE)C holds in every model of the KB.
Figure 22. Basic Asks w.r.t. Individuals
GetTypes gets all classes of which an individual is an instance of as depicted in Figure 23. 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 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 23. Basic Query w.r.t. Individual Instantiation
Figure 24 show the the GetDisjointIndividuals 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 24. Retrieving Disjoint Individuals
The equivalent individuals to an individual are returned as result to the query GetEquivalentIndividuals (Figure 25) 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 (GetFlattenedDisjointIndividuals) return a set of individuals.
Figure 25. Retrieving Equivalent Individuals
To retrieve the object properties originating from a source individual or pointing to a target individual GetObjectPropertiesOfSource and GetObjectPropertiesOfTarget are provided (Figure 26). 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 26 with the exception of the OWL 2 RL profile which does not support this predefined object property.
Figure 26. Querying Instantiated Object Properties between Individuals
Figure 27 shows the asks for checking whether two individuals or an individual and a literal are related via a given property (AreIndividualsRelated resp. IsIndividualRelatedWithLiteral).
Figure 27. Asks for Checking Relatedness
between Individuals and Literals.
In Figure 28 there are the corresponding data property queries from above (Figure 26) 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 28. Querying Instantiated Data Properties
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 29). 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 29. 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 30. Querying Targetss/Sources of
Instantiated Properties (flattened version of Fig. 29)
The queries about related individuals also come in a so called flattened variant as shown in Figure 30. 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.
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 31). 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 31. Querying Targets/Sources of
Instantiated Data Properties
The former also comes with a flattened variant (see Figure 32) 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 32. Querying Targets/Sources of
Instantiated Data Properties (flattened version of Fig. 31)
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.