OWLlink:
HTTP/Functional Binding

Abstract

The OWLlink interface provides an implementation-neutral mechanism for accessing OWL reasoner functionality. This document defines a concrete binding of OWLlink which exploits HTTP/1.1 as the transport protocol and an extended OWL 2 functional-style syntax for the message syntax.

Status of this Document

Please Comment

The OWLlink Working Group seeks public feedback on this Working Group Recommendation. Please send your comments to public-comments@owllink.org or post to the public discussion forum at http://www.owllink.org/forum/.

1. Preliminaries

This document presents the OWLlink HTTP/Functional Binding, a functional-style syntax for OWLlink, called OWLlink Functional for short. OWLlink Functional employs [HTTP/1.1] as the underlying transport protocol. As such, standard notions and features from the HTTP protocol apply (e.g., sessions, content encoding and compression, etc.).

The abstract syntax of OWLlink messages is specified in the [OWLlink Structural Specification] in terms of UML. This document specifies a concrete syntax for these abstract OWLlink messages. It employs the standard OWL 2 functional-style syntax for OWL 2 axioms and descriptions of any kind (e.g., class descriptions, datatype descriptions, etc.) As a result, developers of OWLlink components can easily reuse their parsers resp. generators to implement the two bindings. The remaining OWLlink expressions are given a functional-style syntax which is analogous to the OWL 2 functional-style syntax.

1.1 Example Request

To exemplify this, consider the following OWLlink message in the OWLlink HTTP/XML binding, which adds an OWL 2 ClassAssertion axiom to a freshly created knowledge base http://www.owllink.org/KB_1, and asks for the instances of the Father class:

This message takes the following form in the OWLlink Functional binding:

The details of this syntax translation are described in Section 2.

1.2 Namespaces

As a substitute for XML namespaces we propose a new message which extends the structural OWLlink specification, namely the NamespacePrefix message. For demonstration purposes, the namespace prefix owl is declared as a shorthand for the namespace <http://www.w3.org/2002/07/owl#> in the example message above. As a consequence, owl.ClassAssertion can be used instead of <http://www.w3.org/2002/07/owl#ClassAssertion>, very similar to XML namespaces. Note that OWLlink Functional assumes that the OWL 2 standard namespace prefixes rdf, rdfs, xsd, owl can be used without explicit declaration, as well as ol for the OWLlink namespace http://www.owllink.org/owllink#. Moreover, all the elements from these namespaces can be used without prefix notation, so ClassAssertion is synonym for owl.ClassAssertion. Regarding ol.Literal and owl.Literal, it is required that an OWLlink Functional implementation can disambiguate these Literals from their syntactic context, e.g., no explicit disambiguation is required here.

However, namespace disambiguation is required in case an element appears in more than one namespace, e.g. an element may appear in two different OWLlink extensions which shall be used simultaneously in a request. Then, either fully qualified names have to be used, or namespace prefixes have to be declared and used, as illustrated.

A set of such optional namespace prefix declarations has to appear before the RequestMessage (ResponseMessage) message, and the scope of such a prefix declarations is the current request/response pair only.

Please note that the NamespacePrefix message is rather different from the OWLlink Prefix message. Whereas the latter declares KB-specific prefixes to be used in abbreviated IRIs in attribute values, the former is required as a substitute for XML namespaces. In the following we thus explicitly distinguish namespace prefixes from prefixes. An OWLlink Functional implementation must not support namespace prefixes; in this case, fully qualified names have to be used for extensions.

1.3 Attribute Handling

To specify attributes and their values, an associative argument-passing style is used by employing the Attribute element, e.g. Attribute(kb <http://www.owllink.org/KB_1>). Note that this is an OWLlink Functional specific message. Although this seems verbose at first sight, this argument passing-style is robust the sense that the message syntax will not break if additional attributes are added to an element in a future version of OWLlink or an OWLlink extension. Moreover, a "by position"-based argument-passing scheme has the disadvantage that optional arguments complicate the message parsing, and optional arguments may have to be bypassed by supplying empty values such as nil, resulting in a non-robust message syntax with respect to future extensions or changes of the messages.

1.4 Example Response

In order to also present an OWLlink ResponseMessage, consider the valid OWLlink XML/HTTP response to the request given above:

In OWLlink Functional, this message takes the following form:

2. Functional Binding

The functional binding specifies a concrete syntax for OWLlink abstract messages which are specified in terms of UML class diagrams, the [OWLlink Structural Specification]. The adopted syntax is very similar to the OWL 2 functional-style syntax, which is the main syntax in the [OWL 2 Specification]. In the same way as the OWL 2 XML syntax can be considered as a syntactic variant of the OWL 2 functional syntax, the OWLlink Functional syntax can be considered as a syntactic variant of the [OWLlink HTTP/XML Binding].

The set of well-formed OWLlink Functional messages is specified by a transformation which maps abstract OWLlink messages and thus, object graphs conforming to these UML diagrams, into concrete messages in OWLlink functional syntax. The transformation is specified by the two recursive transformation functions T and AT given below.

Consider an abstract OWLlink message as an object graph of the corresponding UML diagram. If i is a direct OWLlink instance (message) or OWL 2 instance (message) of type (UML class) c in this graph, and i has attribute values v_1, ..., v_n for the attributes a_1, ..., a_n of types t_1, ..., t_n (n may be zero), and also has associations ac_1, ..., ac_m to further instances (messages) i_1, ..., i_m (m may be zero) of types c_1, ..., c_m (the ranges of the associations), and if i is itself possibly the source individual of some association ac (ac is nil in case i is a root individual in the object graph), then the concrete syntax of i is given by T(i,c,ac), where T is the translation function specified below. Note that, if i is a root node and thus c is either RequestMessage or a ResponseMessage, then the OWLlink functional concrete syntax is given by T(i,c,nil). In general, T(i,c,ac) is specified as follows. Note that terminal content is specified in double quotes in this specification.

1. If c is owl.IRI and ac is not nil, then T(i,c,ac) is given as

         "Attribute(" IRI i' ")"
       

   and i' is specified in the [OWL 2 Specification] ("Attribute" is a literal of the grammar, hence it specified in double quotes).

2. If c is owl.fullIRI, then T(i,c,ac) is given as

         "Attribute(" ac i' ")" 
       

   and i' is specified in the [OWL 2 Specification].

3. If c is either owl.Class, owl.ObjectProperty, owl.DataProperty, owl.Datatype, owl.Individual, or owl.AnnotationProperty, then i' is rendered either as a owl.fullIRIs or as an owl.abbreviatedIRIs (in case the implementation abbreviates IRIs), as specified by the OWL 2 functional-style syntax.This may depend on the Prefixes which are defined for the corresponding OWLlink KB from (or to) which this messages comes from (or goes to, resp.) given the implementation supports abbreviated IRIs. Note that the set of Prefixes is knowledge-base specific in OWLlink.
4. If c denotes an OWL 2 UML class (i.e., those prefixed with owl. in the [OWLlink Specification]) which has not been covered by the preceeding clauses, then T(i,c,ac) is given as

         f "(" ... ")"
       

   as specified in the [OWL 2 Specification]. In extension to the official OWL 2 functional-style syntax, also

         prefix.f "(" ... ")" 
       

   may be used, where prefix is either some declared NamespacePrefix for <http://www.w3.org/2002/07/owl#>, or owl. Moreover, a fully qualified syntax may be used:

         "<http://www.w3.org/2002/07/owl#"f">" "(" ... ")" 
       

5. Otherwise, i is an OWLlink message. The result of T(i,c,ac) is then given as

         c' "(" 
               TA(v_1,a_1)
                   ... 
               TA(v_n,a_n)
          
               T(i_1,c_1,ac_1) 
                   ...
               T(i_m,c_m,ac_m) 
            ")"
       

   where either c'=nsprefix.postfix if some namespace prefix nsprefix is defined for the namespace (an IRI) such that c is the concatenation of namespace and postfix, or c' is <c>, i.e. c' is the owl.fullIRI of c as specified by the OWL 2 functional-style syntax, if no such namespace prefix nsprefix is declared, or the implementation does not support namespace prefixes. Moreover, if nsprefix is one of ol, rdf, rdfs, xsd, owl, simply postfix may be used for c'. It is required that an OWLlink Functional implementation can disambiguate e.g. owl.Literal and ol.Literal from the syntactic context.

   The notion of declared namespace prefixes is explained below. An implementation may also "invent" new namespace prefixes but it is then required that the corresponding NamespacePrefix declarations appear in any response generated by this implementation. The standard namespace prefixs declarations may not appear in a response.

   Whereas for attributes, the order in which attributes are translated is not important, the translation order matters for certain i_l (referenced via associations) in some OWLlink messages such as IsClassSubsumedBy. This ordering is specified in Section '2.2 XML Schema' [OWLlink HTTP/XML Binding] and is adopted for the bindings described in this document as well.

   Moreover, TA is the attribute translation function: If v is an attribute value (e.g., the string "true") of attribute a (e.g., result) of type t (e.g., string), then TA(v,a) is specified as follows:

    
         "Attribute(" a v' ")"
       

   and v' is thus either a String, Int, or Boolean (these are the "conceptual" primitive datatypes used in the [OWLlink Structural Specification]). Boolean values are rendered as strings "true" and "false". String are double quoted strings; the encoding of the character content is addressed at the HTTP level (HTTP content encoding; UTF8 is suggested). Note that the backslash character ("\") serves as the escape character in strings.

In addition to the OWLlink messages, the OWLlink Functional binding defines one additional messages. Any number of NamespacePrefix messages may appear in a OWLlink HTTP request (response) before the RequestMessage (ResponstMessage). The message has the following form:

NamespacePrefix(nsprefix owl.fullIRI)

nsprefix may be a quoted string in terms of OWL 2 or simply a sequence of characters (without double quotes and whitespaces). This is basically owl.prefixName, but without colon at the end.

The scope of a namespace prefix declaration is the current HTTP request and the corresponding response. It is assumed that the following prefixes are automatically declared with their standard namespaces and thus need not be declared again: ol, rdf, rdfs, xsd, owl. Moreover, elements from these namespaces can be referred to without prefix notation, e.g., ClassAssertion instead of owl.ClassAssertion or even <http://www.w3.org/2002/07/owl#ClassAssertion>.

An implementation must include those user-defined non-standard NamespacePrefixes in a response which are actually used in that response to the request for which these prefixes have been declared. However, the set of standard prefix declarations for ol, rdf, rdfs, xsd, owl are never included in a OWLlink Functional response.

3. Examples

This Section present the example request and response messages from Section '4 Examples' [OWLlink HTTP/XML Binding] in Functional Syntax.

3.1 Introspecting Reasoner Capabilities

GetDescription request.

GetDescription response.

3.2 Creating Knowledge Bases

CreateKB request.

CreateKB response.

3.3 Retrieving Settings

GetSettings request.

GetSettings response.

3.4 Changing Settings

Set request.

Set response.

3.5 Declaring Prefixes

Prefix request.

Prefix response. Note that the fourth GetSubclass request raises an error, since it refers to the unqualified class A which relies on the XML base xml:base="http://www.owllink.org/examples/myOntology#" in the corresponding HTTP/XML example. Since there is no such feature in OWLlink functional, A cannot be resolved to http://www.owllink.org/examples/myOntology#A.

3.6 Loading Ontologies

LoadOntologies request.

LoadOntologies response.

3.7 Pooling Requests

Pooling request.

Pooling response.

3.8 Retrieving Taxonomies

Taxonomy request.

Taxonomy response.

4. References

[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/.

[OWLlink Structural Specification]

OWLlink: Structural Specification Thorsten Liebig, Marko Luther, Olaf Noppens. Working Group Recommendation, 16 November 2009, http://www.owllink.org/owllink-20091116/.Latest version available at http://www.owllink.org/owllink/.

[OWLlink HTTP/XML Binding]

OWLlink: HTTP/XML Binding Olaf Noppens, Marko Luther, Thorsten Liebig, Michael Wessel. Working Group Recommendation, 16 November 2009, http://www.owllink.org/owllink-httpxml-20091116/. Latest version available at http://www.owllink.org/owllink-httpxml/.

[OWLlink HTTP/S-Expression Binding]

OWLlink: HTTP/S-Expression Binding Michael Wessel. Working Group Recommendation, 16 November 2009, http://www.owllink.org/owllink-httpsexpr-20091116/. Latest version available at http://www.owllink.org/owllink-httpsexpr/.

[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.