InteliGrid Ontology Framework

Result at a Glance

Motivation

• To provide ontology definitions for all high-level entities relevant to a distributed VO environment, with flexibility for further domain-specific extensions
• To provide semantic services with directory functionality for all kind of resources and entities in the grid environment To foster semantic interoperability for all grid services
• To realise semantic Business Process Object integration

Main characteristics

• All developed and applied ontologies based on OWL as single ontology language
• Ontology Services realised as standard Grid Services with WSDL interfaces
• Ontology Services provide complex semantic information about the whole grid environment, including ontology-based resource metadata
• Support for semantic modelling and management of Virtual Organisations
• Integrated support for semantic Business Process Objects
• Ontology-based reasoning as well as standard request methods provided for convenience
• SPARQL used as querying language; response based on XML/RDF

Main outcome

• Conceptual model for Ontology Framework in Grid Environments
• Ontology Definitions for organisational data (including VO modelling), services and resources, as well as a Business Process Object Ontology
• Basic and advanced Ontology Services implemented in Java and deployed as Grid Services.

Result description

The concept of the InteliGrid Ontology Framework for semantic VO interoperability together with its intended use in the VO environment is shown in the figure below. On the right hand side it presents schematically the envisaged run-time VO environment using the semantic grid paradigm. Users of the environment connect to it via their ontology-based virtual desktops that provide access to all environment services. On the left hand side the figure shows the principal components of the ontology framework providing the basis for achieving semantic interoperability and collaboration.

It is important to under-stand that concepts defined in the ontologies on the left side of the figure act as semantic proxies of entities in the “real” environment. They allow capturing se-mantic metadata about the things in the distributed run-time environment in a cohe-rent way, albeit separated from the real entity itself. Thus it becomes possible to provide semantic informa-tion in a flexible metadata framework for semantic VO interoperability. Due to various reasons (already existing specifications and services, security/performance considera­tions etc.) run-time components cannot be expected to be fully conformant with the ontology specifications comprising the semantic framework. Therefore, in the middle part of the figure typical mapping components are shown that have the task to “translate” ontology concepts to existing practical schemas and data structures as e.g. the RBAC model defining access rights and authorisation of users. Whilst at this level many different variations are theoretically possible, current technologies appear to converge to a relatively small set of specifications. This makes the mapping task manageable in the context of specific industry contexts as e.g. scenarios for the AEC domain.

Ontology definitions are structured into four separate, yet interconnected specifications:

• The Resource Ontology is dedicated to the representation of all data resources available in the environment (files, documents, databases, product models, product model views, etc.). Its possible domain extensions may incorporate ontological representations of domain product data models such as IFC in the AEC domain or PLCS in the aeronautic industry.
• The Service Ontology (OWL-S as is) formally defines the available grid services using the definitions of the Resource Ontology to specify the content exchanged/provided by the grid services. Domain extension of this ontology is optional and may provide service subclasses that are more tightly bound to respective business requirements.
• The Organisational Ontology defines the concepts of VO actors, VO structure, persons, organisations and roles together with the respective access control and authorisation constraints.
• The Business Process Ontology plays a superior role in the developed framework. It is the ontology that provides encompassing view on the environment, enables direct relationship to business processes and related business requirements, and can even be used as basis to support workflow management. Whilst it is not mandatory to use this ontology in a run-time environment, it provides the greatest semantic depth and the most comprehensive interoperability capabilities to both users and services.

The Resource, Services and Organisational ontologies only reference each other but are not dependent on the Business Process Ontology. They can also be used independently, providing basic semantic descriptions related to organisational entities, resources and services that can be implemented within a generic Ontology Service. On the contrary, the Business Process Ontology is strongly dependent on these lower level core ontologies, which enables it to provide more complex semantic support.

This modular modelling approach enables different levels of support and different configurations of the environment for each specific case. It also greatly facilitates the modular development of the respective ontology services by clearly defining their information and functionality boundaries. The Ontology Services in the scope of InteliGrid constitute the layer “Semantic Interoperability Services” in the architecture. They are connected to the Business Services and make use of the Grid Middleware Services for authorisation management and generic access to grid resources.

The Ontology Services provide generic and specific (convenience) methods to create, manipulate and manage ontology instances of classes defined in the described ontologies. Interfaces make use of the XML-based OWL notation for data exchange. The SPARQL query language is used for ontology query functionality. Convenience methods provide access to instances of dedicated ontology classes and facilitate their management, e.g. createProject(…), deletePerson(), etc. Such methods are impor­tant for less powerful clients (without elaborated semantic functionality), and can improve acceptance of semantic services in general.

Within the services, structured ontology management on model and entity level is developed utilising the Jena Semantic Web Framework for Java. Persistent storage for ontology data and models of the Ontology Services is provided by a back-end database (MySQL). Database integration is part of the Jena Framework realised by an abstract Java interface for model management on ontology databases.

For clients based on Java a software package is developed that facilitates the handling of ontology instances based on the deployed ontologies. This package allows bi-directional mapping of the XML-based OWL notation (used by the Service Interfaces) to Java objects, thereby enabling the manipulation of instances of ontology classes and their properties in object-oriented way. Experiences in the InteliGrid project have shown that the acceptance of the semantic technology rises remarkably when client developers can use the object-oriented instance model for semantic interoperability.