OWLlink

Paper Title: 
OWLlink
Authors: 
Thorsten Liebig, Marko Luther, Olaf Noppens, and Michael Wessel
Abstract: 
A semantic application typically is a heterogenous system of interconnected components, most notably a reasoner. OWLlink is an implementation-neutral protocol for communication between OWL2 components, published as a W3C member submission. It specifies how to manage reasoning engines and their Knowledge Bases, how to assert axioms, and how to query inference results. A key feature of OWLlink is its extensibility, which allows the addition of required functionality to the protocol. We introduce the OWLlink structural specification as well as three bindings which use HTTP as concrete transport protocol for exchanging OWLlink messages rendered according to selected OWL2 syntaxes. Finally, we report on existing APIs, reasoners and applications that implement OWLlink.
Full PDF Version: 
Submission type: 
Tool/System Report
Responsible editor: 
Decision/Status: 
Accept
Reviews: 

This file is the final version. The reviews below are for the original submission.

Review 1 by Ernesto Jimenez-Ruiz:

The paper presents OWLlink, an interesting proposal for a client-server protocol to allow communication between OWL 2 applications. OWLlink aims at abstracting the implementation of the client (e.g. ontology engineering tool) and the server (e.g. reasoner) sides.
The paper is well described as a 'tool/system' paper. OWLlink and related plugin for Protege 4 are available for download.

(1) Quality, importance, and impact of the described tool or system.

Scalability is an important issue when dealing with large ontologies. Reasoning with such ontologies in current desktop computers is usually a hard task and sometimes it consumes all the computational resources. Delegating this hard task to a high performance server seems to be the best solution. In this regard, OWLlink presents a protocol to allow this solution, and proposes an extensible system in which new services can be integrated. Racer Pro currently implements the OWLlink protocol. For the other Java-based reasoner, such as HermiT, OWLlink implements a client server API on top the OWL API.

Regarding the OWLlink protocol there are interesting services that are not considered: e.g., concurrency and modularity. It is assumed that they could be developed and integrated with OWLlink as external OWL-like systems. However, it would be interesting to provide an analysis of how concurrency could be integrated within the protocol, that is, how OWLlink could be used in a multiuser scenario such as the collaborative development of ontologies.

Modularity (e.g., [1,2]) would be also an important service to provide. Since we aim at delegating the hard work to the server side, the extraction of relevant ontology fragments would ease the analysis in the client side.

[1] Bernardo Cuenca Grau, Ian Horrocks, Yevgeny Kazakov and Ulrike Sattler. Modular Reuse of Ontologies: Theory and Practice. J. of Artificial Intelligence Research (JAIR). Vol. 31. Pages 273-318. 2008.
[2] Boris Konev, Carsten Lutz, Dirk Walther, and Frank Wolter. Semantic modularity and module extraction in description logic. Proceedings of ECAI 2008

(2) Clarity, illustration, and readability of the describing

The paper is well written and easy to understand. However further comparison with related work would be necessary to fully understand the capabilities of OWLlink. In the introduction is given an overview of related approaches but the reader expects a more comprehensive comparison. A Future Work section would also serve to clarify future extensions and functionalities of OWLlink.

If there are space limitations, some of the Figures 5-10 could be removed and refer the technical report.

Review 2 by anonymous reviewer:

This paper reviews the OWLlink protocol specification that supersedes the now outdated DIG interface for communicating between OWL reasoners (server) and applications (client). This work is practically relevant since it provides a generic communication interface via which OWL reasoners can be addressed, irrespective of the technical details of their implementation. Many reasoners today directly use the OWL API for providing reasoning services, but this solution always requires a Java binding that may not be available or suitable for all implementations (examples include implementations Lisp or OCaml, such as CEL and CD). OWLlink closes this gap.

The work fits the scope of this special issue very well. It is not a research work as such -- there is no evaluation and clear methodology -- but it is practically relevant. A publication in this journal could be useful as a reference for works that build upon this technology.

The paper is mostly well written, with understandable language, careful typesetting and a sensible overall structure. The main problem of the paper is that it is sometimes too vague to get a clear idea about the technical details of OWLlink. My main questions are listed below. These points need to be clarified in the final version (if more space is needed, Fig. 2 could be removed without much loss of content).

(1) How do the OWLlink reasoning requests (basic asks) relate to the formal semantics of OWL? The paper states that requests such as "IsEntailed" return "true" or "false", while the OWL 2 specification states that conformant reasoners may return "true", "false", or "unknown". If this is somehow covered by OWLlink, the paper should be precise about how the criteria in the "OWL 2 Conformance" document relate to the answers that OWLlink implementations should give.

(2) More generally, which requirements does OWLlink impose onto implementations that claim to support (a certain form of) OWL reasoning? If an OWLlink implementation reports that "OWL 2" is supported, does OWLlink require it to process the standard asks according to the OWL 2 specification, or does OWLlink not require semantic conformance? The answer to question (1) might help to clarify in which sense conformance is required. For example, I wondered if OWLlink implementations must be complete when computing Synsets, or if it is enough if they are sound for this task. Phrased as a concrete question: if a reasoner implements OWLlink but does sometimes return semantically equivalent classes in different Synsets, can it still be a "correct" OWLlink implementation?

(3) How does the specification of supported languages and semantics work in an interoperable fashion? The paper says that the configurations selectedProfile and appliedSemantics must always be supported. But how do the values of these configurations refer to, say, "OWL 2 QL under Direct Semantics". Are there fixed identifiers to denote this language (having URIs for ontology languages could be useful as such!)? If the methods just returns a string "OWL2" then one would already loose interoperability if another tool returns "OWL 2" instead. But if there are standard names for common languages, then there must be a list of them, which would define a core set of languages/semantics that OWLlink supports (of course, it would be easy to extend). It would be interesting to see this list if available.

(4) Which reasoners can practically be used with OWLlink today? Only RacerPro is mentioned explicitly (overall, the implementation section is very much focussed on RacerPro). The authors also mention that there is a modified version of the OWL API that supports OWLlink, so I assume that every reasoner that uses the OWL API can be recompiled with this modified version to get OWLlink support. But for the casual reader, it might be helpful to explicitly mention which popular reasoners this comprises (surely Pellet and HermiT, but what about FacT++ and tools like Quonto or CEL?). Also the paper says that the modified OWL API implements the OWL Reasoner interface. Does that mean, that tools that support OWL Reasoner can be used with OWLlink without recompiling them with the modified OWL API? Again, it would be good to have a list of the tools that this affects. The paper says that one can "turn existing OWL API version 2 and 3 reasoners into OWLlink servers" but does not explain if this "turning into" involves re-compilation or not. If re-compilation is needed, it would be interesting if pre-compiled binaries for popular reasoners were available.

Explicitly mentioning supported tools will help to underline the significance of the paper.

(5) What version of Protege are you referring to, and where can I download the OWLlink-enabled version of Protege that is mentioned? It would also be useful to give version numbers for other tools, in particular for the reasoners that are mentioned (currently just one, but I hope that this changes).

I am sure that these points can be clarified by the authors before camera ready, so I consider the changes as minor.

Other minor comments:
* "split up from" -> "separated from"
* Although some differences about URIs and versioning are mentioned in the middle of the paper, I found the distinction between knowledge base and ontology slightly confusing; it might help to add an earlier note about what the difference actually is. When you say that KBs do not have a version URI, does that mean that the OWL 2 version information is not accessible via OWLlink?
* "Since there are activities aiming at widely accepted ontology query languages we expect corresponding OWLlink extensions in the near future." Could you be more specific here? Do you refer to the work of the SPARQL WG or to some other activity? Is there a concrete OWLlink extension being worked on now?
* For citing OWL 2, please consider citing the "OWL 2 Overview" (it still makes sense to cite the other documents you mention for their specific contents but the overview is the main entry point for the specification as such).
* "cf." indicates a (typically contrasting) comparison and should not be used where "see" is meant (occurs multiple times).
* At the end of Section 2.1, you say that the server may "close the session". Please explain what this means. The protocols that are used in the current bindings do not seem to support sessions. Is the notion of a "session" part of OWLlink or of the underlying communication channel?
* "appliedSemantic" (s missing)
* Fig. 2 refers to "ox:Axiom". Should this be "owl:Axiom"?
* "a collections of classes" (s too much)
* Try to put Fig. 3 at the very top of its page. There is currently one line of text above it, making it harder to read the text.
* Section 2.4 says that "[The response to GetSubClassHierarchy] eliminates all redundant subsumption relationships" I would expect that this involves the restriction to "direct" subsumptions, i.e. to a skeleton of subsumptions from which the whole set follows by transitive closure (various tools offer this operation). This is not what you do here, or is it?
* "More precisely, it omits all those synsets within the pairs of direct super-/subclasses, which contain the owl:Nothing class." This sentence has a problem. I think that whole "pairs" are removed, not just the synsets that occur in these pairs. Also, it is unclear from this sentence if the pairs do only contain direct subclass relationships or not (previous remark).
* "the structurally specification" (ly too much)
* "requests an responses" (d missing)
* "A corresponding server responses" (s too much)
* There are some overfull hboxes; check your LaTeX output. The worst is in Section 3.2, line 1.
* page 8: |specified as strings "true", "false"| The quotation mark after "true" is slanted.
* You say that HERAKLES is "some proprietary protocol". In the light of this remark, it would be useful to specify what the status of OWLlink is -- isn't it also a proprietary protocol in the same sense? Is it planned to make it into a standard?

I am not sure if the Appendix is very useful, given that there are online documents that give full details. Maybe some examples taken from the appendix could instead be given in a figure or table in the main text, together with a reference to the complete listing of basic asks.

Tags: 

Comments