We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.ArchitectureDescription.Data.SemanticSupport R3 - FIWARE Forge Wiki

FIWARE.ArchitectureDescription.Data.SemanticSupport R3

From FIWARE Forge Wiki

Jump to: navigation, search
FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Contents

Copyright

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

Target usage

Target users are mainly ontology engineers and developers of semantically-enabled applications that need RDF storage and retrieval capabilities. Other GE from the FI-WARE, such as for example the GE for semantic service composition, the query broker, or from the usage areas of the PPP that need semantic infrastructure for storage and querying are also target users of this GE [SAS].

Semantic Application Support GE Description

The Semantic Web Application Support enabler aims at providing an effective environment for developers to implement and deploy high quality Semantic Web-based applications. The Semantic Web was first envisioned more than a decade ago by Tim Berners-Lee, as a way of turning the Web into a set of resources understandable not only for humans, but also by machines (software agents or programs), increasing its exploitation capabilities [Bizer 2009]. The Semantic Web has focused the efforts of many researchers, institutions and IT practitioners, and received a fair amount of investment from European and other governmental bodies. As a result of these efforts, a large amount of mark-up languages, techniques and applications, ranging from semantic search engines to query answering system, have been developed. Nevertheless, the adoption of Semantic Web from the IT industry is still following a slow and painful process.

In recent years, several discussions had taken place to find out the reasons preventing Semantic Web paradigm adoption. There is a general agreement that those reasons range from technical (lack of infrastructure to meet industry requirements in terms of scalability, performance. distribution, security, etc.) to engineering (not general uptake of methodologies, lack of best practices and supporting tools), and finally commercial aspects (difficulties to penetrate in the market, lack of understanding of the main strengths and weaknesses of the semantic technologies by company managers, no good sales strategies, etc.).

The Semantic Application Support enabler addresses part of the abovementioned problems (engineering and technical) from a data management point of view, by providing:

  • An infrastructure for metadata publishing, retrieving and subscribing that meets industry requirements like scalability, distribution and security. From now and so on, we will refer to this infrastructure as SAS Infrastructure.
  • A set of tools for infrastructure and data management, supporting most adopted methodologies and best practices. From now and so on, we will refer to these tools as SAS Engineering Environment.

Example Scenario

There is a need for semantically-enabled applications in many fields and domains, ranging from research projects to enterprise intranets or public web sites. Semantic applications often rely on ontologies and knowledge bases to develop business functionality such as discovery, composition, annotation, etc., with the aim of enhancing exploitation capabilities of resource (services, text documents, media documents, etc.). The need for an infrastructure that eases the development, storage and use of ontologies and allows practitioners to efficiently manage their knowledge bases, providing the means to manage metadata effectively is therefore of paramount interest.

The TaToo (http://www.tatoo-fp7.eu/tatooweb/) project can be taken as an example in order to show how this generic enabler can help future Internet application developers. TaToo is a research project in the environmental domain with the goal of developing tools to facilitate the discovery of environmental resources. In order to enhance the discovery process, one of the applications stores annotations (metadata) of existing environmental resources by tagging them with ontology terms. Therefore, an ontology framework [Pariente 2011] has been developed including three domain ontologies that describe three different environmental domains plus a bridge ontology that allows cross domain interoperability. Moreover, TaToo ontologies are not built from scratch but by reusing (completely or partially) existing ontologies publicly available on the Internet. Nowadays the TaToo ontology framework is the result of the integration of more than 15 ontologies. The development of such a framework is a complex task, involving several domain experts and ontology developers. By hence, the use of a methodology, as well as a set of tools to assist in the process of ontology engineering will be required. In TaToo, the NeOn Methodology [Suarez-Figueroa 2008] and the NeOn Toolkit [NeOn-Toolkit], one of the baseline assets of this generic enabler, have been the basis for the ontology engineering process. The Neon Toolkit helped TaToo’s ontology developers to apply the NeOn methodology to develop ontologies providing several functionality such us ontology edition, ontology modularization, ontology search, etc. Besides, these ontologies are expected to evolve over time, and would therefore need a system that helps the ontology expert to tackle the ontology evolution problems. This is not completely covered by the NeOn Toolkit, as there are aspects such as ontology versioning, knowledge base maintenance, workspace environments, etc. that are not fully covered by the tool. These functionalities has been developed in the scope of FI-WARE project. Next figure shows a screenshot of NeOn Toolkit being used in the scope of TaToo.

NeOn Toolkit screenshot

Once ontologies are developed they need to be uploaded to a knowledge base with inference capabilities to be used by business logic components. In TaToo, Sesame [Sesame] and OWLIM [OWLIM], two of the assets selected as baseline assets for this enabler, have been used as knowledge base implementation. However, Sesame and OWLIM are RDF / OWL oriented storages, so there is a lack of knowledge base management capabilities. As an example, once an ontology is loaded into a Sesame workspace, it is not possible to keep tracking management over it. In case the ontology evolves over time, there is no possibility to track the workspace in order to look for the incremental updates over the ontology. This kind of knowledge base management problems are solved by the Semantic Support Application.

To summarize, a project such as TaToo might benefit from an enabler that provides an ontology and knowledge base management system integrated with an ontology engineering environment. This environment will supports strong ontology development methodology, covering the whole semantic web application lifecycle. This is clearly extensible to many different Semantic Web-based applications.

Basic Concepts

This section introduces the basic concepts related to the Semantic Support Application GE including ontologies, ontology languages and ontology development methodologies.

Ontologies

[Gruber 1993] introduced the concept of ontology as “a formal explicit specification of a shared conceptualization”. Thus, in the Semantic Web, ontologies play the role of a formal (machine-understandable) and shared (in a domain) backbone. Ontologies are becoming a clear way to deal with integration and exploitation of resources in the several domains. Starting from Gruber’s definition is it possible to infer some of the key features that make ontologies a valuable knowledge engineering product:

  • Ontologies are formal, so they are supposed to be machine-understandable.
  • Ontologies have explicit definitions, so they are storable, interchangeable, manageable, etc.
  • Ontologies are shared, so they are supposed to be agreed, supported and accessible by a broad community of interest.
  • Ontologies are a conceptualization, so they are supposed to be expressive enough to model wide knowledge areas.

In order to efficiently develop ontology networks that fulfil these features, a wide range of elements are needed, ranging from appropriate methodologies, to tools supporting those methodologies and appropriate infrastructures to allow management of the ontology lifecycle. Providing such a support is the aim of this GE.

To do so, some decisions have been taken in order to limit the scope of the GE:

  • To select [OWL-2 RL] as reference language for ontology formalization.
  • To select NeOn Methodology [Suarez-Figueroa 2008] as reference methodology for ontology development.

Both decisions will be discussed in the following sections.

OWL-2

Since the inception of the ontologies, several ontology languages, with different expressivity, serialization and underlying logic formalisms have risen and fallen (OWL, WSML, F-Logic, OIL, KIF, etc.). Sometimes these languages differ in their serialization, sometimes in their background logic and sometimes they are just designed with a different purpose. Therefore, providing functionality for every single ontology language is almost an impossible task. In consequence, in the scope of the Semantic Web Application Generic Enabler, OWL-RL (a decidable subset of OWL, the W3C standard and most popular ontology language) has been selected as reference for ontology definition. Some of the reasons supporting this decision are now introduced:

  • Since October 2009, OWL-2 is a W3C recommendation for ontology definition.
  • OWL-2 RL provides a good trade-off between expressivity and performance. Inference over OWL-2 RL guarantees that inference process will finish in a reasonable amount of time.
  • OWL-2 RL is based in previous W3C standards such as [RDF] and [RDFs] so previous ontologies could be also managed by the proposed infrastructure.

Ontology Engineering

SAS GE aims to provide the means for FI Applications developers to develop Semantic Web enabled applications efficiently. Ontology development, one of the key points in these applications, is a complex, expensive and time-consuming process that includes different activities, such as specifying requirements, information extraction, logical modeling, etc. In order to efficiently manage this process, it is necessary to use a methodology and its supporting tools. Due to its adoption and maturity, Semantic Application Support GE provides the means to support the NeOn Methodology. The NeOn Methodology defines a methodology for ontology development that covers the whole ontology lifecycle. The NeOn methodology includes extracted elements of previous methodologies like METHONTOLOGY [Fernandez 1997], On-To-Knowledge [OnToKnowledge 2001] and DILIGENT [DILIGENT 2004]. The NeOn methodology increases the level of descriptive detail, and provides two new features: ontology creation from existing resources (both ontological or not) and ontology contextualization. In this way, NeOn offers a general methodology for ontology development useful across different technological platforms and that specifies each process and activity of the methodology, defining its purpose, inputs, outputs, involved actors, applicable techniques, tools and methods, when its execution is necessary, etc.

Image:NeOnMethodology-FIWARE.png
NeOn Methodology overview (from Suárez-Figueroa, 2008, with permission)

The NeOn methodology presents and describes nine of the most common scenarios that may arise during ontology development:

  1. Specification for implementation from scratch.
  2. Reusing and re-engineering non-ontological resources.
  3. Reusing ontological resources.
  4. Reusing and re-engineering ontological resources.
  5. Reusing and merging ontological resources.
  6. Reusing, merging and re-engineering ontological resources.
  7. Reusing ontology design patterns.
  8. Restructuring ontological resources.
  9. Localizing ontological resources.

The first scenario represents the typical case where the ontology is built from scratch; the other scenarios involve different levels of reuse of other resources, those scenarios are visually described in previous figure. For each of all these scenarios, the NeOn methodology establishes detailed guidelines, tools to use, etc. The Semantic Web Application Support GE provides a technological support for those guidelines.

Semantic Application Support GE Architecture

The objective of the Semantic Application Support GE is to facilitate the Ontology Engineering process providing a set of tools that allow the ontology reutilization using repositories to publish and share ontologies between projects. The developer can use the published ontologies to create semantic repositories to support specific needs.

In order to satisfy the previous objective, the Semantic Application Support GE is divided in a client-side Engineering Environment and a server-side Infrastructure. Next figure presents the SAS Infrastructure architecture.

SAS Architecture

As it is shown in the diagram, it follows a typical three layer Java Enterprise Architecture. Components included in business and presentation layers are JEE based. In the data layer, two components can be found:

  • A relational database, which will be used by Ontology Registry to store ontology documents loaded into the GE.
  • A Knowledge Base providing OWL-2RL support. This Knowledge Base will be used by ontology and workspace registries to store ontology and workspace related metadata and by managing, querying and publishing modules to provide their functionality.

Business components will interact with data layer components by means of two different mechanisms. On the one hand to interact with the relational database, business components will use JPA (Java Persistence API) that make business components database system independent. On the other hand, business components interacting with the knowledge base will be knowledge base implementation dependent. In Semantic Application Support reference implementation, the combination of Sesame and OWLIM has been chosen as knowledge base implementation.

Business Layer contains following components:

  • Ontology registry that manages ontologies loaded into the system and its related metadata. Operations such as retrieving / uploading ontology, retrieving / uploading metadata, etc would be provided by this component. A description of methods provided can be found in Backend Functionality section.
  • Workspace registry that manages workspaces and their related metadata created by users to be used by their semantic enable applications. Operations such us creating / deleting a workspace, listing ontologies loaded into the workspace is provided by this component.
  • Publishing module that allow user to publish data into the GE. Data can be either ontologies or RDF serialized content. In case of ontologies, publishing module will rely on ontology registry functionality. In case of RDF serialized content, publishing module will store the content in proper knowledge base workspace in collaboration with workspace registry. In both cases publishing module will update subscription module if needed.
  • Managing module that allow users to monitor the status of the GE. Operations such as retrieving a list of available ontologies, retrieving a list of subscriptions, etc will be provided by this module. Managing module will rely on the rest of business components to provide its functionality.
  • Subscription module that allows users to subscribe to events produced in the GE. Operations such as subscribing to ontology updates or workspace modifications will be provided by this module.
  • Querying module that allows users to query their workspace following SPARQL Query Protocol.

In order to provide GE functionality in a platform independent way, several Rest APIs was developed. This allows to clients or presentation layer applications to interact with business components by means of HTTP requests / responses.

Main Interactions

Modules and Interfaces

This section reports on the description of the Semantic Web Application Support GE main functionality. The description of this functionality is based on the functionality provided by the baseline asset in FI-WARE first release. Section Backend functionality describes functionality (methods) provided to agents in a service like style. Section Frontend functionality describes functionality provided to human users through a GUI.

Backend Functionality

Backend functionality describes functionality provided by the GE as service invocation methods for both human or computer agents. As described in Architecture section [SAS Architecture], this functionality is accessible by means of Rest Web Services API. In this second FI-WARE release, a sub set of methods belonging to publishing, managing, semantic workspaces management and semantic workspaces operations rest APIs will be provided:

  • Publishing Rest API.
    • Get ontology version: Retrieves from the GE the ontology document identified by a given ontology IRI (obtained using the list ontologies service) and version IRI. To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI>/<version IRI>.
    • Get ontology: Similar to Get ontology version. It retrieves from the GE the latest version of the ontology document identified by a given ontology IRI (obtained using the list ontologies service). To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI>.
    • Delete ontology version: Removes from the GE the ontology document identified by a given ontology IRI (obtained using the list ontologies service) and version IRI. To invoke the operation, a DELETE http request should be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI>/<version IRI>.
    • Delete ontology: Similar to Delete ontology version. It removes from the GE the latest version of the ontology document identified by a given ontology IRI (obtained using the list ontologies service). To invoke the operation, a DELETE http request will be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI>.
    • Upload ontology version: Uploads to the GE an ontology document and identifies it with a given ontology IRI (obtained using the list ontologies service) and version IRI. To invoke the operation, a PUT http request should be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI>/<version IRI> with a file attachment including the ontology RDF/XML serialization.
    • Upload ontology: Similar to Upload ontology version. Uploads an ontology document to the GE and identifies it with a given ontology IRI and with the latest version IRI available. To invoke the operation, a PUT http request should be sent to http://<ge url location>/ontology-registry/ontologies/<ontology IRI> with an file attachment including the ontology RDF/XML serialization.
    • Get ontology version metadata: Retrieves from the GE an ontology document containing the metadata related to an ontology document identified by a given ontology IRI (obtained using the list ontologies service) and version IRI. To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI>/<version IRI>.
    • Get ontology metadata: Similar to Get ontology version metadata. It retrieves from the GE an ontology document containing the metadata related to the latest version of the ontology document identified by a given ontology IRI (obtained using the list ontologies service). To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI>.
    • Delete ontology version metadata: Removes from the GE the metadata related to an ontology document identified by a given ontology IRI and version IRI. To invoke the operation, a DELETE http request will be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI>/<version IRI>.
    • Delete ontology metadata: Similar to Delete ontology version metadata. Removes from the GE the metadata related to the latest version of the ontology document identified by a given ontology IRI. To invoke the operation, a DELETE http request should be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI>.
    • Upload ontology version metadata: Uploads to the GE an ontology document containing metadata related to an ontology document identified by a given ontology IRI (obtained using the list ontologies service) and version IRI. To invoke the operation, a PUT http request should be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI>/<version IRI> with an file attachement including the metadata RDF/XML serialization. Metadata uploaded must complain to OMV (Ontology metadata vocabulary).
    • Upload ontology metadata: Similar to Upload ontology version metadata. It uploads to the GE an ontology document containing metadata related to the latest version of an ontology document identified by a given IRI (obtained using the list ontologies service). To invoke the operation, a PUT http request should be sent to http://<ge url location>/ontology-registry/metadata/<ontology IRI> with a file attachment including the metadata RDF/XML serialization. Metadata uploaded must complain to OMV (Ontology metadata vocabulary).
  • Managing Rest API.
    • List ontologies: Retrieves an XML document containing the list of ontology documents and their versions loaded into the GE. To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/mgm/list. The output is an xml encoding the requested information that will be sent as response.
    • List ontology versions: Similar to List ontologies. Retrieves an XML document containing the versions of an ontology document identified by a given ontology IRI loaded into the GE. To invoke the operation, a GET http request should be sent to http://<ge url location>/ontology-registry/mgm/<ontology IRI>. The output is an xml encoding the requested information that will be sent as response.
  • Workspaces Management Rest API.
    • List Workspaces: Retrieves an XML document which contains a list of all workspaces managed by the server, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/mgm/list. The output is an xml encoding the list of workspaces.
    • Workspace Operations Rest API.
    • Create Workspace: Creates a new semantic workspace, a POST http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]. The output is an xml document encoding the result of the operation.
    • Remove Workspace: Remove an existing semantic workspace, a DELETE http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]. The output is an xml encoding the result of the operation.
    • Duplicate Workspace: Creates a duplicate of a existing workspace with his metadata (ontologies and triples), a PUT http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/duplicate. The output is an xml document encoding the result of the operation.
    • Execute Query: Execute a SPARQL query into a existing workspace, a POST http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/sparql/. The output is an xml document encoding the result of the query.
    • Get Workspace: Retrieves the RDF from a specific workspace, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]. The output is a RDF/XML encoding the data.
    • Get ontologies updates: Retrieves a list of available updates for the ontologies included in a workspace, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/checkupdates. The output is a XML encoding the list of updates.
    • Load Ontology: Load an ontology into a workspace from a specific ontology registry, a POST http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/ontology/[ONTOLOGY_NAME]. The output is a XML encoding the operation result.
    • List Ontologies: Retrieves a list with the ontologies included in a workspace, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/ontology/list. The output is a XML encoding the list of ontologies.
    • Update ontology: Update an ontology included in a workspace using a specific ontology registry, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/ontology/[ONTOLOGY_NAME]/update. The output is a XML encoding the result of the operation.
    • Delete Ontology: Delete an ontology from a workspace , a DELETE http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/ontology/[ONTOLOGY_NAME]. The output is an XML document encoding the operation result.
    • Create Context with RDF: Create a context with RDF data into an existing workspace , a POST http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/[CONTEXT_NAME]. The context will be cleared and then the RDF will be loaded. The output is an xml document encoding the result of the operation.
    • Load RDF into Context: Load RDF data into a context of an existing workspace , a PUT http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/[CONTEXT_NAME]. The context will be cleared and then the RDF will be loaded. The output is an xml document encoding the result of the operation.
    • Delete Context: Removes a context of a specific workspace, a DELETE http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/[CONTEXT_NAME]. The output is a XML encoding the result of the operation.
    • List Contexts: List the contexts included in a specific workspace, a GET http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/list. The output is a XML encoding the list of context.
    • Add Statement: Add a statement (RDF triple) into a specific workspace, a POST http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/[CONTEXT_NAME]/statement. The output is a XML encoding the result of the operation.
    • Remove Statement: Remove a statement (RDF triple) from a specific workspace, a DELETE http request should be sent to http://<ge url location>/semantic-workspaces-service/rest/workspaces/[WORKSPACE_NAME]/context/[CONTEXT_NAME]/statement. The output is a XML encoding the result of the operation.

All methods described can be invoked by means of regular HTTP requests either using a web browser (for those ones who rely on GET requests) or by a APIs such as Jersey.

Frontend Functionality

SAS Web User interface is based on the functionality provided by the Web Protégé. The Web Protégé is the web version of Protégé [WebProtege], a well-know ontology editor, which provides comprehensive support for the ontology engineering life-cycle. Due to its nature, it wouldn’t be possible to describe all SAS Engineering Environment provided functionality in a service like manner. Anyway, an overview of the functionality required for the SAS Engineering Environment is now introduced. Some screenshots from Web Protégé will be used in this section to provide a better understanding of the SAS functionalities. Figure below presents an overview of Web GUI.

Web Protégé main window

Most of the functionality provided by SAS Web UI is provided as editors, views and perspectives. Next figure presents the Ontology navigation perspective.

Image:ProtegeNavigator.jpg
Ontology navigation perspective

Under this perspective users are able to manage their projects and ontologies, creating or removing projects, loading or creating new ontologies, etc. In the scope of a given ontology, users are able to manage (adding, removing, etc) main ontology contents such as classes, properties and individuals. Once selected, ontology contents can be edited by means of a proper editor. Next figure presents the class editor.

Image:ProtegeClassEditor.jpg
Class editor

Properties provide functionalities to represent the interactions between classes and individuals. The Properties view allows managing the ontology’s properties and its related metadata. Next figure presents the properties view.

Properties View

The SAS Web UI interacts with the Ontology Registry and Semantic Workspaces allowing to retrieve and modify the ontological resources contained in these components. As the SAS Web UI is based on the widely used Protégé editor will be easy to any developer to use this Web UI, this fact facilitate the diffusion of the Semantic Application Support GE in the Semantic developers community.

Design Principles

The main goal of the Semantic Web Application Enabler is to provide a framework for ontology engineers and developers of semantically-enabled applications offering RDF/OWL management, storage, and retrieval capabilities. This goal will be achieved by providing an infrastructure for metadata publication, retrieval, and subscription that meets industry requirements like scalability, distribution, and security, plus a set of tools for infrastructure and metadata-data management, supporting most adopted methodologies and best practices.

The Semantic Web Application enabler is based on the following design principles:

  • Support standards: Support for RDF/OWL, the most common standards used in Semantic Web applications.
  • Methodological approach: GE is strongly influenced by methodological approaches, so it will adopt and support, as far as possible, most adopted methodologies to achieve its goals.
  • Semantic repository features: Provide high-level common features valid for most of the existing solutions in the semantic web in terms of RDF / OWL storage and inference functionalities.
  • Ontology management: The enabler will provide an ontology registry and the API to control it, including some high-level ontology management functionalities.
  • Knowledge Base management: The enabler will provide a knowledge base registry and the API to control it, including some high-level knowledge-base management functionalities.
  • Extensibility: The most important part of the architecture design of the enabler is to define interfaces that allow the extensibility of the system. Where applicable the design should also be modular, to facilitate future extensions and improvements. The reference implementations should comply with this common design.

For the Ontology Registry component, some decisions regarding the design have been taken, including: selection of an ontology metadata format, definition of a format for ontology identifiers, definition of an interface for exposing ontology-(?)registry functionality and decision on how to store ontologies.

In order to provide advanced ontology management, ontologies should be annotated with extended metadata. In order to do so, the selection of a suitable ontology metadata format is needed. In this case, the Ontology Metadata Vocabulary [OMV] has been selected. Some of its key features are:

  • OWL-2 An ontology developed in the NeOn project following the NeOn Methodology.
  • Designed to meet NeOn Methodology reusability use-case requirements.
  • Extensible, reusable, accessible, and interoperable.

OMV describes some metadata regarding ontologies that should be provided by users while loading ontologies into the GE. This metadata include information about ontology developers, ontology language, ontologies imported by the ontology, etc. A class diagram showing OMV main classes and attributes can be found in the figure below.

Ontology Metadata Vocabulary UML diagram

In order to be stored into the ontology registry, it would be needed to assign to the ontology a unique identifier. Identifying ontologies may seem to be an easy task but it is not even completely tackled, even in OWL-2 specification. Taking a look into the OWL-2 specification it can be found that:

  • Each ontology may have ontology IRI, which is used to identify an ontology. If an ontology has an ontology IRI, the ontology may additionally have a version IRI, which is used to identify the version of the ontology.
  • The ontology document of an ontology O should be accessible via the IRIs determined by the following rules:
    • If O does not contain an ontology IRI (and, consequently, it does not contain a version IRI either), then the ontology document of O may be accessible via any IRI.
    • If O contains an ontology IRI OI but no version IRI, then the ontology document of O should be accessible via the IRI OI.
    • If O contains an ontology IRI OI and a version IRI VI, then the ontology document of O should be accessible via the IRI VI; furthermore, if O is the current version of the ontology series with the IRI OI, then the ontology document of O should also be accessible via the IRI OI.

For the sake of the implementation, in the scope of the Semantic Application Support, ontologies must have ontology IRI and version IRI. Ontology IRI must be provided by the user while version IRI may be provided by the GE in some cases. Moreover, ontology documents will be accessible using their ontology IRI plus version IRI, being this last one optional. In case no version IRI is provided, the latest version of the ontology identified by the ontology IRI will be provided while accessing.

The Semantic Application Support GE will need to store then two kinds of resources: ontologies and ontology metadata. Having selected OMV as ontology metadata format, ontology metadata would need to be stored into a RDF triple store with OWL capabilities. In case of ontologies, they will be managed as plain text objects and stored in a regular relational database. This would avoid potential performance problems while serving ontologies for developers for editing purposes.

Finally, an interface for accessing the ontology registry will be provided. In this case, Semantic Application Support GE will follow [SPARQL Query protocol]: If a service supports HTTP bindings, it must support the bindings as described in the specification. A SPARQL Protocol service may support other interfaces such as SOAP. In the case of this GE, a RESTful based service will implement the interface of the ontology registry. This interface is described in main interactions section.


References

[Pariente 2011] Lobo, T. P., Lopez J. M. F., Sanguino M. A., Yurtsever S., Avellino G., Rizzoli A. E., et al. (2011). A Model for Semantic Annotation of Environmental Resources: The TaToo Semantic Framework. ISESS 2011.
[Bizer 2009] Bizer, C., Heath, T., & Berners-Lee, T. (2011). Linked Data - The Story So Far. International Journal on Semantic Web and Information Systems, 5(3), 1-22.
[Suarez-Figueroa 2008] Suárez-Figueroa, M. C., et al. NeOn D5.4.1. NeOn Methodology for Building Contextualized Ontology Networks. February 2008.
[NeOn-Toolkit] The NeOn Toolkit, http://neon-toolkit.org/
[Sesame] Sesame RDF framework, http://www.openrdf.org/
[OWLIM] OWL Semantic Repository, http://www.ontotext.com/owlim/
[Gruber 1993] Gruber, T.: A translation approach to portable ontology specifications. Knowledge Acquisition 5, 1993
[OWL-2 RL] http://www.w3.org/TR/owl-profiles/#OWL_2_RL
[RDF] Beckett D., RDF/XML Syntax Specification (Revised). W3C Recommendation, 10 February 2004
[RDFs] Dan Brickley D, Guha R.V., RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation, 10 February 2004
[Fernandez 1997] Fernández-López M., Gómez-Pérez, A. & Juristo, N.: Methontology: from ontological art towards ontological engineering. Proc. Symposium on Ontological Engineering of AAAI, 1997
[OnToKnowledge 2001] Broekstra, J., Kampman, A., Query Language Definition. On-To-Knowledge (IST-1999-10132), 2001
[DILIGENT 2004] Pinto H.S., Tempich C., Staab S., Sure Y.: Diligent: Towards a fine-grained methodology for distributed, loosely-controlled and evolving engineering of ontologies. In de M´antaras L.R., Saitta L., editors, Proceedings of the 16th European Conference on Artificial Intelligence (ECAI 2004), August 22nd - 27th, pages 393–397, Valencia, Spain, AUG 2004. IOS Press.
[OMV] Jens Hartmann, Raúl Palma, York Sure, María del Carmen Suárez-Figueroa, Peter Haase, Asunción Gómez-Pérez, Rudi Studer: Ontology Metadata Vocabulary and Applications. OTM Workshops 2005: 906-915
[SPARQL Query protocol] http://www.w3.org/TR/rdf-sparql-protocol/
[WebProtege] http://protegewiki.stanford.edu/wiki/WebProtege
Personal tools
Create a book