
Motivation

• Limitations of existing ontology editors - Prototyping with Protègè 2000 has shown conceptual

and interface design limitations

• Need for an extendable component based WSMO editor within different research projects

• Release of Eclipse 3.0 as ideal platform for devoloping component based IDEs


Functional Requirements

• A WSMO Studio needs to handle Ontologies, Goals, Mediators and Web Services

• For all WSMO elements it is required to edit complex logical formulas

• Compatibility with existing formalisms such as RDF and OWL

• Extensibility to adopt WSMO Studio for different research projects

• Reusability of components by other programs

• Usability and tool support

• Integration of Reasoning Support


Functional Requirements: WSML Variants

WSML provides several variants with different logical expressivity that need to be handled by WSMO Studio:

•WSML-Core: defined by the intersection of DL and Horn Logic

•WSML-DL: extension of WSML-Core which captures the DL SHOIN(D)

•WSML-Flight: extension of WSML-Core with several features of OWL Full

•WSML-Rule: extension of WSML-core that supports Horn Logic

•WSML-Full: unifies WSML-DL and WSML-Rule under FOL


Architecture

• The WSMO API and its reference implementation provides unified programmatic access to WSMO descriptions. An implementation of the Storage API will provide access to e.g. WSML files

• Stand Alone Applications reuse the WSMO API, e.g. a Java Servlet that performs online validation/translation of WSML files.

• WSMO Studio Runtime is an Eclipse based core plug-in without GUI elements that provides functionality to other WSMO Eclipse plug-ins, e.g. Ontology-plug-in

WSMO API

EXTERNALPROGRAM

DBFile

Eclipse Platform

WSMO Eclipse Runtime

WS

MX

plu

g-i

n

Ma

pp

ing

plu

g-in

On

tolo

gy

plu

g-i

n

Storage API

Represenation API


WSMO API

• WSMO API provides an interface that can have different actual implementations, reusable in various programs.

• The API consists of two layers:

- Representation API provides methods to query and modify the data model (including logical expressions), e.g. the interface Concept would have methods like getSuperConcepts()or addAttribute(Attribute)and the interface Instance would have methods like getAttributeValue(Attribute) or setAttributeValue(Attribute,AttributeValue)

- Storage API provides a standardized way to load a model from and to export it to a data source

• The API comes with a reference implementation and should be open source


WSMO Studio Runtime and Studio Plug-ins

• The Eclipse based WSMO Studio Runtime- provides methods for calling the WSMO API

- provides ressource management via the API

- is a host plug-in that provide well defined extension points for Studio Plug-ins

- registers Studio plug-ins and manages inter plug-in communication

• Eclipse based Studio plug-ins – plug into the WSMO Studio Runtime and provide WSMO based

services, e.g. a WSML editor and browser, a validator, editor and reasoner for different logical expressions, a mapping tool between different ontologies or a WSMX plug-in

The Runtime should be open source, the license for plug-ins can be

choosen


Eclipse for WSMO Studio

• Eclipse is a kind of universal tool platform – an extensible IDE for anything and nothing in particular with significant back up in industry and open source projects

• Eclipse is based on a well documented component model with well defined extension points.

• Some plug-ins (e.g. UML plug-in for WSMO visualisation) may be reusable

• Eclipse allows the implementation of more professional user interfaces than Swing via SWT based native platform look and feel but on the other hand existing Swing based components can hardly be reused

• Eclipse has a fast growing user community and backup from other projects (DIP)

• The initial effort for learning and implementing Eclipse plug-ins is higher than with stand-alone custom development


Eclipse based Implementation

• Eclipse itself is constructed out of a set of plug-ins, e.g. the workbench provides functionality for a "project explorer"

• WSMO runtime is envisioned as Workbench Core plug-in that defines extension points, registers plug-ins and provides access to the in memory model via WSMO API

• Plug-ins such as an ontology editor should be based onto the WSMO runtime plug-in that provides access to the WSMO model. Additionally the plug-ins can directly use functionality provided by the platform such as the Help System


WSML Text Editor for Eclipse

Prototype of a WSML text editor with syntax highlighting based on an Eclipse Multipage Editor Plugin


Future plans

• Achieve common agreement on WSMO API

• Implementation of importer/exporter for WSML

• Implementation of an Eclipse based WSMO Runtime

• Implementation of a WSML editing and browsing tool

• Implementation of a standalone application based on WSMO API (validation/transformation servlet)


</studio>

<q&a>

Contents

Documents

Transcript of Contents