Introduction

Ontology repositories have been considered a key resource for building a global infrastructure to enable the vision of the Semantic Web [1]. Many ontology repository systems exist for publishing and sharing ontologies and vocabularies for content indexing, information retrieval, content integration, and other purposes, e.g. Cupboard [2], BioPortal [3], OOR [4], and ONKI [5].

However, currently each ontology repository is a separate island, with no connections with other repositories. This means that, e.g. global search, browsing, or inference over the repositories can not be done, which creates a hindrance for using the ontologies globally. For example, searching for the concepts with the label "fish" from all existing ontology repositories around the Internet is currently not possible although many ontology repositories surely contain ontologies with matching concepts. Because the user may not find the correct ontology or concept for one's needs, it means that:

the quality of annotations may decrease if the optimal concept is not found, redundant new ontologies are created if the existing ontologies are not found, interlinking of data decreases due to creating redundant ontologies, and merging data for semantic web applications becomes more difficult due to the need for ontology matching.

As a solution to the problem of how to access the repositories globally, in the spirit of the Linked Open Data1 [6], we propose a Linked Open Ontology Services (LOOS) architecture consisting of ontology repositories that publish their content through common API, and thus making it possible to access the different ontology services in a distributed way.

In the following, we present the proposed architecture and API. Then, a proof of concept implementation of clients and servers is described. Finally, related work is discussed and contributions of the paper summarized.

LOOS API and Metadata About Services

The LOOS Network consists of ontology repositories that publish their content using a common, uniform LOOS API. A key idea of the LOOS API is to hide the ontology schema specific representations (such as OWL and RDFS) behind a uniform, simplified, SKOS-like representation of the key elements of the ontology: the concepts and their relations. Hiding ontological details makes it easier both to provide a uniform API to the ontologies and to display the search results from the underlying repositories in a uniform way to the user. After finding the matching ontology or concept, if the full power of a specific ontology representation is needed, the user can be directed to the specific ontology repository.

The main methods of the API are following:2

search: search concepts -getLabels: get the labels of a concept -getEquivalentConcepts: get the equivalents of a concept -getConceptHierarchy: get the concept hierarchy of a concept -getFullPresentation: get all the information about a concept -getDirectory: get the directory view of an ontology

The search method is used for finding concepts using various restrictions, such as text, concept type, or parent concept. The method returns a list of matching concepts. To get information about each concept, the properties and relations of a concept can be queried using methods such as getLabels. For efficiency, the getFullPresentation method returns all information about a certain concept in a single request. When browsing an ontology, an overview of the ontology is helpful. To support this, the getDirectory method returns an ontology-specific overview of the given ontology, consisting of e.g. the alphabetical ordering of the concept labels, manually defined grouping of concepts, or the top concepts of the ontology.

We propose implementing the LOOS API as a lightweight, stateless, and cacheable HTTP GET based API that returns data using the JSON format which provides an easy way to add LOOS support to ontology servers.

To find LOOS enabled services, metadata about the services is needed. We use the property loos:APIBaseURL for describing the URL of each LOOS endpoint. Additional information about the ontology such as title and description may be expressed using e.g. the Dublin Core metadata schema. Based on the metadata, e.g. a directory of LOOS services can be published.

The Proof-of-Concept Implementation

The ONKI SKOS ontology server has been used for publishing over 70 ontologies in the Finnish Ontology Library Service ONKI [7]. Global search to the ontologies was however not possible, because the ontologies were running as separate server instances. To solve this problem, and as a proof-of-concept implementation for the LOOS aproach, the LOOS API was implemented to the ONKI SKOS server and the server instances were described with LOOS metadata (see Fig. 1). The ONKI2 Browser3 is a global search and browsing user interface for accessing the LOOS network of ontology servers (the ONKI SKOS servers) in a uniform way . For example, making a global query to all ontology servers can be done (see Fig. 2). ONKI2 was mostly implemented using PHP 4 .

Another client is the JavaScript-based ONKI Selector widget [8] for adding ontological concept search to HTML forms which now supports using the LOOS network as a back-end. As a third client, we implemented also a URI resolver for dereferencing the end-user's ontology concept URI requests to a suitable representation provided via the LOOS network, such as HTML or RDF.

To make client implementation easier, a broker for accessing the LOOS network was implemented. It provides a registry of LOOS enabled ontology servers based on the ontology service metadata, a single access point for using the LOOS network and a cache5 to speed up potentially slow HTTP requests to individual ontology servers. Based on the registry, the broker directs LOOS requests to relevant back-end ontology servers.

Discussion

Compared to more general methods of accessing RDF data, such as SPARQL 6and Linked Data [6], the LOOS approach focuses on ontologies. For example, when querying for the concept hierarchy of a concept via the LOOS API, one does not need to know what RDF properties (e.g. rdfs:subClassOf or skos:broader ) are used in the data to express the hierarchical relations between concepts. The LOOS API restricts the set of possible queries, which makes it easier to implement and use the API in the ontology servers and the client applications.

APIs for accessing ontologies and vocabularies presented previously include the SKOS API 7 and the OWL API 8 . Compared to them, the LOOS API provides a higher abstraction, independent from specific ontology languages. Compared to the API's of BioPortal [3], Swoogle9 and Watson10 , the goal of LOOS is to create a network of ontology servers based on a shared API that is implemented by all services. Therefore, the LOOS API focuses on a few basic methods that reflects the basic functionality of ontology repositories, e.g. concept search. In future, the LOOS API should be made compatible with repository specific APIs.

Ontology servers such as BioPortal and Cupboard support publishing interlinked ontologies, but the ontologies have to be uploaded into a centralized service for a global search. In contrast, in the LOOS approach ontologies can be published using a ontology service that is optimized for the specific ontology and the user's needs while publishing the ontology service's basic functionality via the LOOS API to connect the ontology service to a global network of ontology services.

The loosely coupled LOOS architecture has turned out to be a flexible solution which makes it easy to implement additional clients when needed. Making multiple HTTP requests to back-end servers may be slow, but in our test implementation this lag has not been a problem thanks to the proxy cache between the clients and the back-end servers.

To conclude, this paper argues that the various ontology servers on the web should be made accessible using a common API that would provide a simple but universal methods for accessing the ontology content. As a solution, we propose the LOOS API and a metadata schema for describing the services.