From NeOn Wiki

Oyster-API

Developed by Raul Palma
Review not available
Status not available
Last Update 30.09.2008
Current Version [[current version:= <ask format="template" template="CurrentVersion" limit="1" searchlabel="" sort="version number" order="descending" default="no version available"> 1.x/Oyster-API *</ask>]]
Homepage [http://ontoware.org/projects/oyster2 1.x/Oyster-API Website]
Activity
License EPL
Affiliation
NTKVersion 1.2.3

Ontology Registry


Contents

Functional Description

Oyster is a distributed registry that exploits semantic web techniques in order to provide a solution for exchanging and re-using ontologies and related entities. As an ontology registry , it provides services for storage, cataloging, discovery, management, and retrieval of ontology (and related entities) metadata definitions. To achieve these goals, Oyster implements the proposal for metadata standard OMV (http://omv.ontoware.org) as the way to describe ontologies and related entities, supporting advanced semantic searches of the registered objects and providing services to support the management and evolution of ontologies in distributed environments.

Oyster offers a user driven approach where each peer has its own local registry of ontology metadata and also has access to the information of others registries, thus creating a virtual decentralized ontology metadata registry. The goal is a decentralized knowledge sharing environment using Semantic Web technologies that allows developers to easily share ontologies and related metadata.

The Oyster system (freely available under http://ontoware.org/projects/oyster2/ ) was designed using a service-oriented approach, and it provides a well defined API. Accessing the registry functionalities can be done using directly the API within any application, invoking the web service provided or using the included java-based GUI as a client for the distributed registry. In Oyster, ontologies are used extensively in order to provide its main functions (register metadata, formulating queries, routing queries and processing answers):

  • Creating and importing metadata: Oyster2 enables users to create metadata about ontologies manually, as well as to import ontology files and to automatically extract the ontology metadata available, letting the user to fill in missing values. The ontology metadata entries are aligned and formally represented according to two ontologies: (1) the OMV ontology, (2) a topic hierarchy (i.e. the DMOZ topic hierarchy), which describes specific categories of subjects to define the domain of the ontology.
  • Formulating queries: A user can search for ontologies using simple keyword searches, or using more advanced, semantic searches. Here, queries are formulated in terms of these two ontologies. This means queries can refer to fields like name, acronym, ontology language, etc. or queries may refer to specific topic terms.
  • Routing queries: A user may query a single specific peer (e.g. their own computer, because they can have many ontologies stored locally and finding the right one for a specific task can be time consuming, or users may want to query another peer in particular because this peer is a known big provider of information), or a specific set of peers (e.g. all the member of a specific organization), or the entire network of peers (e.g. when the user has no idea where to search), in which case queries are routed automatically in the network.
  • Processing results: Finally, results matching a query are presented in a result list. The answer of a query might be very large, and contain many duplicates due to the distributed nature and potentially large size of the P2P network. Such duplicates might not be exactly copies because the semi structured nature of the metadata, so the ontologies are used again to measure the semantic similarity between different answers and to remove apparent duplicates.

In addition to the core registry services, Oyster provides advanced services to support the evolution of ontologies, including the following functionality (For additional information we refer the reader to D1.3.1):

  • Change Management: Oyster manages information about ontology changes (represented with the OMV extension: Change Ontology). Each change has a corresponding status to support the process that coordinates the proposal of changes in ontologies (i.e. workflow). When a new change is registered into an Oyster node, Oyster automatically updates the log history keeping track of the chronological order of changes.
  • Workflow Management: Oyster manages information about the actions (represented with a workflow ontology) ontology editors perform collaboratively during the process that coordinates the proposal of changes in ontologies (i.e. workflow). For this task, Oyster (i) takes care of enforcing the constraints imposed by the collaborative workflow, (ii) creates the appropriate action individuals of the workflow ontology and (iii) registers them into the distributed registry.
  • Synchronization: Oyster follows a synchronization approach to propagate ontology changes and related actions that is a combination of a push and pull mechanism. During the synchronization, nodes contact other nodes in the network to exchange updated information (pull changes) and optionally they can push their changes to a specific node (called the push node) such that if a node goes offline before all other nodes pull the new changes, the node changes are not lost.

Oyster Architecture

The high-level design of the architecture of a single Oyster node is shown in the figure below.

Figure1
]

In the following, we briefly discuss the individual components of the system architecture. For a complete description we refer the reader to deliverable 1.4.1.

  • The Local Repository of a node contains the metadata about ontologies and related entities (i.e. OMV instances) that it provides to the network. It supports query formulation and processing and provides the information for peer selection. In Oyster, the Local Repository is based on KAON2 and it supports SPARQL as its query language.
  • The Knowledge Integrator component is responsible for the extraction and integration of knowledge sources (e.g. ontologies) into the Local Repository. This component is also in charge of how duplicate query results are detected and merged.
  • The Query Manager is the component responsible for the coordination of the process of distributing queries. It receives queries from the user interface, API or from other peers. Either way it tries to answer the query or distribute it further according to the content of the query.
  • The Informer component is in charge of proactively advertise the available knowledge of a Peer in the distributed network and to discover peers along with their expertise (i.e. the expertise contains a set of topics (i.e. ontology domains) that the peer is an expert in).
  • The Peer-to-Peer network sub-layer is the component responsible for the network communication between peers. In Oyster, we rely on an RMI based implementation; however, other communication protocols would be possible as well.
  • The Oyster API provides a well defined interface in Java with a set of methods that expose all the registry functionalities (available under http://ontoware.org/projects/oyster2/).
  • The Oyster Web Service encapsulates the Oyster API and provides a free realisation of the NeOn registry service compliant with the eBXml standard (available under http://ontoware.org/projects/oyster2/).


User Documentation

How to install it

  • Download the compressed Plugin release from http://ontoware.org/projects/oyster2
  • Extract and copy the Oyster-API Plugin JAR into the plugins directory inside the filesystem location where NeOn Toolkit is installed.

How to use it

This component does not has a user interface associated and it can be used by any other plug-in. The documentation of the API is available at http://ontoware.org/projects/oyster2/. For additional information we refer the reader to D1.4.1 and D1.3.1.

Covered Activities


Architecture Description of integration with NeOn toolkit

The NeOn basic infrastructure layer consists of a set of core services (e.g. Repository services, Registry services, etc). Oyster is an implementation of the registry services. As it is required, it is based on the OMV ontology meta model. Further, it provides an API and a Web Service interface to query, create, and manipulate ontology metadata information according to the OMV model. The web service provides a loosely couple service at the Engineering components layer. Additionally, Oyster provide additional services to support engineering components that rely on the registry services (e.g. Change Capturing). Finally, Oyster also provide GUI components (i.e. plugins) that implement user interfaces to the registry services.

Figure2

Intended use in case study

Oyster will be used in WP7 as ontology registry.

  • Motivation of using Oyster

One of the goals of the FAO use case partner is that fisheries ontologies produced within WP7 will underpin the Fisheries Stock Depletion Assessment System (FSDAS). However, for such a dynamic domain like fisheries that is continuously evolving, we will need to provide the appropriate support for a successful implementation and service delivery of the FSDAS. In particular, for this task we need to support a collaborative editorial workflow that will allow Ontology editors to consult, validate and modify ontologies keeping track of all changes in a controlled and coherent manner. In this scenario, ontology editors are usually developing/maintaining ontologies collaboratively in a distributed environment. Additionally, ontology editors will have to perform many different tasks (e.g. create mappings, populate ontologies) that require to select the appropriate ontology. The registry is crucial component in the infrastructure to aid in the selection of appropriate ontologies and to support the editorial workflow: first, changes have to be monitored and captured from the ontology editor. Those changes should be formally represented and stored in Oyster which is in charge of the management of the different versions of the ontology. Also, using the registry functionalities, those changes will be searched and retrieved by the visualization components to show e.g. the differences between versions of the ontology and also to provide different views to ontology editors (depending on their role) where they can see the state of those changes. Finally, the registry will be in charge of the propagation of those changes to the distributed copies of the same ontology.

  • Benefits/Advantages of using Oyster
    • Oyster implements the standard proposal for annotating ontologies OMV (Ontology Metadata Vocabulary).
    • Ontology changes are formally represented as an ontology that is an extension to the OMV. Oyster provides the support to store and manage that information.
    • Oyster keeps the track and information about the different versions of ontologies and the relationship between them.
    • Oyster provides a well defined API and a Web Service interface to support the integration with other components (e.g. the visualization component).
    • Oyster is in charge of the propagation of ontology changes in the distributed environment to synchronize distributed copies of the same ontology.
  • Data sets

Currently, Oyster can extract metadata from ontologies in OWL, DAML-OIL and RDFS. Users are annotating ontologies that will become available in the distributed environment. One special big provider will be the Watson Node. For the management of changes, the data set to be used will be the FSDAS ontologies.

  • A usage example aligning to WP7 case study.

For the management of ontologies provenance and statistics (UC-9) the system keeps information about ontologies including changes, use statistics and ontology statistics. For instance, for the maintenance of changes (UC9.1) the system keeps tracks of changes in all ontology elements. That is, the date of creation/editing, the editor that made the change, etc. In Oyster all actions are logged according to the change ontology (see Figure3), which captures among others the required following minimum fields:

  • change
    • description
    • operaton executed
    • timestamp
    • URI
    • user
Figure3