fp6 - 507483(api) of the components provided in the dip architecture document (d6.2, [5]). there is...

DIP Data, Information and Process Integration with Semantic Web Services

FP6 - 507483

Deliverable

D6.3 DIP Component APIs

Vesselin Kirov Atanas Kiryakov

31 January 2005

DIP component APIs

Deliverable 6.3 1

SUMMARY This deliverable provides an overview of the application programming interfaces (API) of the components provided in the DIP architecture document (D6.2, [5]). There is also an overview of the interfaces of additional components, which are not first-class citizens of the architecture, but are still important for a number of other tools and components. Input is taken from several places: (i) the DIP Architecture, D6.2; (ii) the component specifications developed within workpackages WP1, WP2, WP4, and WP5 and (iii) the deliverables specifying the WSMX execution environment. For some of the high-level components (e.g. data mediation) there are more than one actual components specified. The data mediation component counts on an ontology mapping language and component specifications developed within the SEKT project. The level of granularity and maturity of the specification of the different interfaces varies across the components. For some of them, there are fully-operational APIs defined in the corresponding programming language (Java) or web service specification language (WSDL). For many components, the interfaces are still not specified in detail due to the fact that the corresponding aspects of the conceptual framework are not finalized yet. Further, the level of granularity of the presented interfaces is still quite diverse – this could be explained with the early stage of the development of the architecture. While this was an expected situation, the project plan envisions an update of the APIs to be presented in deliverable D6.9 “Revision of the components APIs”. There is a table within the concluding chapter which summarizes the nature, status, and the expectations for each of the component interfaces. It is the understanding of the authors that the currently existing interfaces allow for a reasonably smooth software development in the middle phase of the project. The interfaces defined here should be of interest to the use-case partners and to the technology providers which develop components implementations. Disclaimer: The DIP Consortium is proprietary. There is no warranty for the accuracy or completeness of the information, text, graphics, links or other items contained within this material. This document represents the common view of the consortium and does not necessarily reflect the view of the individual partners.

DIP component APIs

Deliverable 6.3 2

Document Information

IST Project Number

FP6 – 507483 Acronym DIP

Full title DIP Component APIs

Project URL http://dip.semanticweb.org

Document URL EU Project officer Brian Macklin

Deliverable Number 6.3 Title DIP component APIs

Work package Number 6 Title Interoperability and Architecture

Date of delivery Contractual M 12 Actual 31.12.2004

Status Version. 0.1 final

Nature Prototype Report Dissemination

Dissemination Level

Public Consortium

Authors (Partner) Vesselin Kirov (Sirma)

Vesselin Kirov Email [email protected] Responsible Author Partner SIRMA Phone +359 2 9768310

Abstract (for dissemination)

This deliverable provides an overview of the application programming interfaces of the DIP components developed in WP1-5.

Keywords SWS architectures, SWS interoperability, SWS API

Version Log

Issue Date Rev No. Author Change

13.10.04 01 Vesselin Kirov

Initial version of document, outline of the structure

13-11-04 02 Vesselin Kirov

Extended version.

24-11-04 03 Atanas Kiryakov

Revised version, updates to the structure

17-12-04 04 Vesselin Kirov

Extended version, sent for review

31-01-05 05 Atanas Final version. Changes wrt to the reviewers comments, updates wrt to the latest versions of D6.4

DIP component APIs

Deliverable 6.3 3

Kiryakov and D5.2. Formatting, layout improvements.

DIP component APIs

Deliverable 6.3 4

Project Consortium Information Partner Acronym Contact

National University of Ireland Galway

NUIG

Prof. Dr. Christoph Bussler Digital Enterprise Research Institute (DERI) National University of Ireland, Galway Galway Ireland Email: [email protected] Tel: +353 91 512460

Fundacion De La Innovacion.Bankinter

Bankinter

Monica Martinez Montes Fundacion de la Innovation. BankInter Paseo Castellana, 29 28046 Madrid, Spain Email: [email protected] Tel: 916234238

Berlecon Research GmbH

Berlecon

Dr. Thorsten Wichmann Berlecon Research GmbH Oranienburger Str. 32 10117 Berlin, Germany Email: [email protected] Tel: +49 30 2852960

British Telecommunications Plc.

BT

Dr John Davies BT Exact (Orion Floor 5 pp12) Adastral Park Martlesham Ipswich IP5 3RE, United Kingdom Email: [email protected] Tel: +44 1473 609583

Swiss Federal Institute of Technology, Lausanne

EPFL

Prof. Karl Aberer Distributed Information Systems Laboratory

École Polytechnique Féderale de Lausanne

Bât. PSE-A 1015 Lausanne, Switzerland Email : [email protected] Tel: +41 21 693 4679

Essex County Council

Essex

Mary Rowlatt, Essex County Council PO Box 11, County Hall, Duke Street Chelmsford, Essex, CM1 1LX United Kingdom. Email: [email protected] Tel: +44 (0)1245 436524

Forschungszentrum Informatik

FZI

Andreas Abecker Forschungszentrum Informatik Haid-und-Neu Strasse 10-14 76131 Karlsruhe Germany Email: [email protected] Tel: +49 721 9654 0

Institut für Informatik, Leopold-Franzens Universität Innsbruck

UIBK Prof. Dieter Fensel

DIP component APIs

Deliverable 6.3 5

Institute of computer science University of Innsbruck Technikerstr. 25 A-6020 Innsbruck, Austria Email: [email protected] Tel: +43 512 5076485

ILOG SA

ILOG Christian de Sainte Marie 9 Rue de Verdun, 94253 Gentilly, France Email: [email protected] Tel: +33 1 49082981

inubit AG

Inubit Torsten Schmale inubit AG Lützowstraße 105-106 D-10785 Berlin Germany Email: [email protected] Tel: +49 30726112 0

Intelligent Software Components, S.A.

iSOCO

Dr. V. Richard Benjamins, Director R&D Intelligent Software Components, S.A. Pedro de Valdivia 10 28006 Madrid, Spain Email: [email protected] Tel. +34 913 349 797

The Open University

OU

Dr. John Domingue Knowledge Media Institute The Open University, Walton Hall Milton Keynes, MK7 6AA United Kingdom Email: [email protected] Tel.: +44 1908 655014

SAP AG

SAP

Dr. Elmar Dorner SAP Research, CEC Karlsruhe SAP AG Vincenz-Priessnitz-Str. 1 76131 Karlsruhe, Germany Email: [email protected] Tel: +49 721 6902 31

Sirma AI Ltd.

Sirma Atanas Kiryakov, Ontotext Lab, - Sirma AI EAD Office Express IT Centre, 3rd Floor 135 Tzarigradsko Chausse Sofia 1784, Bulgaria Email: [email protected] Tel.: +359 2 9768 303

Tiscali Österreich Gmbh

Tiscali

Dieter Haacker Tiscali Österreich GmbH. Diefenbachgasse 35 A-1150 Vienna Austria Email: [email protected] Tel: +43 1 899 33 160

Unicorn Solution Ltd. Unicorn Jeff Eisenberg

DIP component APIs

Deliverable 6.3 6

Unicorn Solutions Ltd, Malcha Technology Park 1 Jerusalem 96951 Israel Email: [email protected] Tel.: +972 2 6491111

Vrije Universiteit Brussel

VUB

Carlo Wouters Starlab- VUB Vrije Universiteit Brussel Pleinlaan 2, G-10 1050 Brussel ,Belgium Email: [email protected] Tel.: +32 (0) 2 629 3719

DIP component APIs

Deliverable 6.3 7

TABLE OF CONTENTS SUMMARY.......................................................................................................................I TABLE OF CONTENTS................................................................................................. VII 1 INTRODUCTION .....................................................................................................1 2 EXPOSED FUNCTIONALITIES OF THE DIP COMPONENTS.....................................2

2.1 Communication Manager ..............................................................................2 2.2 Execution Manager........................................................................................2 2.3 Event Listeners ..............................................................................................2 2.4 Event Manager...............................................................................................2 2.5 Resource Manager .........................................................................................2 2.6 Discovery.......................................................................................................3 2.7 Invocation ......................................................................................................3 2.8 Mediation (Data) ...........................................................................................3 2.9 Semantic Repository......................................................................................3 2.10 Service Registry.............................................................................................5

2.10.1 Publishing ..............................................................................................5 2.10.2 Retrieval ................................................................................................5

2.11 Choreography and Orchestration (ORCA)....................................................5 3 DIP COMPONENT APIS ........................................................................................6

3.1 Communication Manager ..............................................................................6 3.2 Execution Manager........................................................................................6 3.3 Event Listeners ..............................................................................................6

3.3.1 Interfaces ...............................................................................................6 3.4 Event Manager...............................................................................................6 3.5 Resource Manager .........................................................................................7

3.5.1 Interfaces ...............................................................................................7 3.5.2 Examples ...............................................................................................7

3.6 Discovery.......................................................................................................8 3.6.1 Interfaces ...............................................................................................9

3.7 Invocation ....................................................................................................12 3.8 Mediation (Data) .........................................................................................12

3.8.1 Interfaces .............................................................................................13 3.9 Semantic Repository....................................................................................15 3.10 Web Service Registry ..................................................................................16

3.10.1 Interfaces .............................................................................................16

DIP component APIs

Deliverable 6.3 8

3.10.2 Usage examples ...................................................................................17 3.11 Choreography and Orchestration.................................................................21

3.11.1 Interfaces .............................................................................................21 4 ADDITIONAL COMMON APIS..............................................................................22

4.1 WSMO API and Reference Implementation ...............................................22 4.2 Ontology Management Tools ......................................................................23

5 CONCLUSION .......................................................................................................24 REFERENCES ...............................................................................................................26

FP6 – 504083Deliverable 6.3

1

1 INTRODUCTION This deliverable provides an overview of the application programming interfaces (API) of the components provided in the DIP architecture document (D6.2, [5]). The level of granularity and maturity of the specification of the different interfaces varies across the components. For some of them, there are fully-operational APIs defined in the corresponding programming language (Java) or web service specification language (WSDL). Other components are still not specified in such detail due to the need of further developments of the conceptual framework or the architecture. Examples of how to use these components in the context of the DIP execution environment are provided, whenever it is feasible and possible. A considerable volume of source-code listings are integrated within the corresponding sections of the main body. Although a proper layout would require the listings to be provided as annexes, in this case this is not appropriate, because those represent an essential part of its content. This deliverable takes input from several places: (i) the DIP Architecture, D6.2; (ii) the different component specifications developed within workpackages WP1, WP2, WP4, and WP5 and (iii) the deliverables specifying the WSMX1 execution environment, which provide interface specifications, not available elsewhere. For some of the high-level components (e.g. data mediation) there are more than one actual components specified. Further, the data mediation component counts on an ontology mapping language and component specifications developed within the SEKT2 project. The interfaces defined here should be of interest to the use-case partners and to the technology providers which develop and use component implementations. The content is structured as follows: Section 2 contains short descriptions of the functionalities exposed in each of the components in the DIP architecture; Section 3 presents the APIs of the components plus usage examples; Section 4 describes interfaces of components, which are not part of the execution environment architecture, but still appear to be relevant to integration of the different software developed within DIP. Finally, Section 5 provides a conclusion and a summary table for the component interfaces.

1 http://www.wsmx.org 2 http://sekt.semanticweb.org


2

2 Exposed functionalities of the DIP Components

2.1 Communication Manager The communication manager’s API is the external API for the DIP runtime environment. It handles the incoming SOAP messages to and from web service providers or requesters, validates them and in case they are not WSML descriptions it invokes a message adapter to convert them to WSML.

2.2 Execution Manager This is the central component in DIP. It holds the entire workflow of the execution environment. The workflow could be static (hard-coded) or based on a declarative description of the execution semantics of the system. In [11] the WSMO working group will maintain a description of the execution semantics of WMSO/DIP.

2.3 Event Listeners Each ‘first class’ component in the DIP architecture (for instance, discovery, matchmaker, mediator, etc.) will have a corresponding event listener interface in the execution manager (like the Event Listener components that reside in the WSMX manager [15][13]). These listeners will be responsible to process the corresponding events coming from the event manager. It will be the responsibility of the Execution Manager to register each of the listeners in the Event Manager. That might happen, for instance, when a new component becomes available to the execution manager or when the workflow rules change and new types of messages should be processed.

2.4 Event Manager The event manager handles the event processing in the DIP execution environment. The current implementation uses a fixed set of events and fixed rules for subscribing to those events by a fixed set of worker components. A complete description of the internals of the component can be found in [15].

2.5 Resource Manager The resource manager is a component that abstracts the actual datastores/repositories used in DIP. The idea is that each component needing to store or retrieve data needs only to be concerned about calling this component’s operations in order to store/retrieve DIP objects – all the implementation details about where and how to store the object is up to the implementer of the resource manager. The objects accessed/retrieved through the manager will be identified by a unique URI. It is up to the resource manager implementation to map a logical unique URI to a physical location (whether local or remote). One possible solution to that problem is to expose an additional API to allow mapping of parts of the logical URI (f.e. the domain) to a physical datastore. In the examples to the resource manager (section 3.5.2) we will provide such an example.


3

2.6 Discovery In DIP, when we talk about semantic discovery of web services, we mean the discovery of abstract services [13] represented by formal service capabilities [14] which are part of the semantic description of the web service published in the DIP registry by the provider. The requesters on their part use a goal description to describe their service requirements. So in general the discovery process is defined as a semantic matching of the goal of the requester to the capabilities of the services, known to the registry. The result is a set of services matching the goal.

2.7 Invocation The DIP execution environment will implement two distinct types of Web Service invocations. Whenever the choreography/orchestration component needs to invoke a web service that is known to be implemented through DIP/WSMX then the invocation can be translated into a simple call to the remote DIP execution environment that would pass a WSML document. In cases when the service that has to be called is a traditional web service the invoker needs to find a registered message adapter that can convert the WSML call into a call to the traditional web service. The current implementation expects the WSDL description of the web service to be available with the semantic web service description. In the future versions WSMO will provide grounding directly from the web service description.

2.8 Mediation (Data) There are two sorts of mediation needed when two components cannot communicate directly but need to interact. On one hand, data mediation is required in the case when one component is not capable to (correctly and fully) interpret the content of a message sent by another component. On the other, process mediation is necessary in case the two components cannot negotiate on a single interaction protocol. Here we address the data-mediation component only, because the role and function of the process mediation are to be specified later on (D5.3 is due M18, see also section 2.4 of D6.2, [5]). The basic functionality of a data mediation module is to transform messages from source format to a target one, which could require both syntactic and semantic transformation. The mediation approach considered in [7], involves two phases: design-time and run-time. The mappings are created manually or semi-automatically design-time in order to assure correctness in the fully-automatic run-time phase.

2.9 Semantic Repository The semantic repository (SEMR) is an ontology server which allows for storage, retrieval, and querying of ontologies and other data: semantic web service descriptions, instance data, etc. Within the architecture of DIP, there is no clear separation between the functions of an ontology reasoner and a repository. As outlined in D2.2, [8], a key role of the semantic repository is to provide an integrated and semantically uniform access to data which originally comes from diverse data-sources.


4

With most of the reasoning paradigms, there are several inference-specific tasks, e.g. satisfiability checking and realization (instance classification). In the context of a semantic web services infrastructure, the components, not directly involved in ontology management, are not expected to directly request these tasks. The typical requests to the semantic repository will be for storage, retrieval, or querying. The existence of a reasoner will only have an effect on the “quality” of the results of these operations, but not to the interfaces required. For instance, suppose there are facts asserted saying that <partOf, type, TransitiveProperty> <Sofia, partOf, Bulgaria> <Bulgaria, partOf, Europe>

Than suppose a query asking for all parts of Europe is sent to the system. A repository, which is equipped with a reasoner which “understands” the semantic of the transitive properties, will return Sofia as an answer, while a “dumb” repository will not, because this fact is not explicitly asserted. Similar considerations can be applied to the different sorts of ontology management tools. There is no doubt, that those represent an important part of an integrated solution, because they allow for basic tasks such as ontology editing and mediation. However, this functionality is not directly accessed in the context of a web-service execution environment. The ontology tools help managing the ontologies and the data stored in the repository, which is the access point for all the remaining ontology-aware applications and tools. This is interaction schema is demonstrated at Figure 1.

Figure 1. Interactions with the Semantic Repository

The semantic repository component in DIP is required to serve at least the following groups of tools:

• Ontology management tools, those developed in WP1 and WP2;

• Semantic Web Service development tools (WSMO Studio and others, WP4);

Semantic Repository(Repository and/or Reasoner)

Ontology Management Tools

Structured Data-Source(Database, Ontology Server)

Clients(Ontology-Aware Systems)


5

• Semantic Web Service execution environment (WSMX and WP4). SEMR should also provide a proper framework for execution of ontology-mapping-based semantic transformation in the course of data mediation, see [7].

2.10 Service Registry This component is specified in D4.2, [6], and provides to the other DIP components an API that facilitates the publishing and non-semantic (syntactic and structural) retrieval of DIP elements (ontologies, mediators, goals, DIP web services etc.). D4.2 states that the registry will contain links to the semantic information about the published DIP elements and that the retrieval process will be able to return these links based on search using UDDI v2 query language. Two main use cases for the API have been identified in D4.2 – the discovery process and the (semi-)automatic service composition. It has to be considered that the strategy for interoperation between SWS and WS infrastructure is still subject of research discussion and experiments. Thus, it could be the case that the vision underlying the repository specification provided in D4.2 could face modifications in the course of the project.

2.10.1 Publishing The publishing functionality of the DIP registry will be available as a web service that has operations to publish a DIP Web Service, a Mediator Service, Ontology and a Goal. In order to facilitate the retrieval of these elements through the standard UDDI find functionality, some of the WSMO ([14]) non-functional properties will be stored directly in the underlying UDDI registry (e.g. title, identifier, etc.). Then it would be possible to find the DIP object based on these properties. The complete list can be found in D4.2, [6], chapter 4.

2.10.2 Retrieval The retrieval of DIP elements from the registry will be available as a web service that provides operations to retrieve DIP Web Services, Mediator Services, Ontologies or Goals according to certain search criteria. The search criteria is based on the WSMO non-functional properties that are mapped into the underlying UDDI registry; the AND, OR or LIKE find qualifiers and wildcards (limited to the title property).

2.11 Choreography and Orchestration (ORCA) This component implements the choreography and orchestration in the DIP execution environment as defined in WSMO. As such, each message coming in to the DIP execution environment passes through ORCA and each message going out is initiated by ORCA and passed through the invoker. Also, this component takes the responsibility to maintain the state of each conversation with an external entity – through a choreography instance when the invocation is incoming to the DIP environment or through the orchestration when the invocation is outgoing from the DIP environment.


6

3 DIP Component APIs

3.1 Communication Manager The APIs of the communication manager will be described in a separate deliverable D6.4, [4], and they will be seen as the main entry point of the DIP execution environment.

3.2 Execution Manager The execution manager will manage the internal workflow of the DIP environment. In the current WSMX implementation the execution semantics is hard-coded and as such there is no need for APIs to this component. In the future the internal workflow will be described declaratively and at that stage we envision adding external APIs to the component. The first interface we expect to have will be called Registrar and it will enable the components doing the actual work in the execution environment to register/unregister dynamically from the manager. Another interface called Configuration will enable other components (f.e. an administrative front-end) to change the workflow rules or the components to be used for specific tasks. Based on the current configuration and workflow rules the execution manager will register the appropriate event types in the event manager and will also create and register all the event listeners it will need to do its work.

3.3 Event Listeners Event listener is a common name for the set of interfaces a component should expose in order to subscribe to events in the Event Manager of DIP. At the moment two main components are identified that will expose such interfaces and respectively will receive events from the event manager – the Execution Manager and the Communication Manager. The Execution Manager will register the event listeners for all the tasks performed during the processing of a request to the DIP runtime (f.e. matchmaking, discovery, mediation). The Communication Manager will register a listener for an end of processing event so it will know when to return the results back to the original requester.

3.3.1 Interfaces The event listeners expose a single interface called EventListener with a single operation called handleNewEvent(Event) that returns a status indicating whether the event was consumed by the listener or not.

3.4 Event Manager The current implementation of the event manager does not need any external APIs since all the subscriptions and all the subscribed components are hard-coded. In the next revisions of this document we may add an API that will enable dynamic change of the subscription policies and the types of events.


7

In that case the API will expose two interfaces: the EventFactory interface that would enable components to register/unregister types of events or to create events and EventListenerFactory that will be the one the components would use to subscribe/unsubscribe to events.

3.5 Resource Manager The resource manager will be provided as a Java component (possibly an EJB).

3.5.1 Interfaces The manager will expose one interface called ResourceManager with two operations: void store(DIPObject objectToStore,URI logicalURI) DIPObject get(URI logicalURI)

One possible implementation of the mapping of a logical URI to a physical location is to implement an additional interface called ResourceMapper with a single operation void map(URI partialLogicalURI,URI physicalURI). An example of such a solution will be provided in the next sub-section. A similar mapping problem is also addressed with the Locator interface of the WSMO API (section 4.1), which maps logical IDs to physical addresses for WSMO elements.

3.5.2 Examples The first example shows how to use the ResourceManager interface. package org.semanticweb.dip.examples.ResourceManager; import java.net.URI; public class Manager { public static void main(String[] args) { try { URI logicalCityURI = new URI(

"http://test.dip.org/ontologies/locations/city.wsml"); ResourceManagerInterface resourceManager =resourceManagerHome.getManager(); resourceManager.store(cityOntology,logicalCityURI); DIPObject cityOntologyCopy=resourceManager.get(logicalCityURI); if(!cityOntologyCopy.equals(cityOntology)) { System.out.println("Error storing the ontology"); } } catch(Exception ex) {ex.printStackTrace();} } }

The second example shows a possible implementation of the mapping of logical URIs to physical locations. Follows the interface declaration:


8

package org.semanticweb.dip.ResourceManager; import java.net.URI; public interface Mapper { public void mapPhysicalURI(URI partialLogicalURI,URI physicalLocation) throws Exception; public URI getPhysicalURI(URI fullLogicalURI) throws Exception; }

And this is a possible implementation: package org.semanticweb.dip.ResourceManager; import java.net.URI; import java.util.Hashtable; import java.net.URISyntaxException; public class MapperImpl implements Mapper { /** * This class keeps mappings of logical domains to physical URIs */ Hashtable mappings=new Hashtable(); /** * Maps the domain part of a logical URI to a physical store. * @param logicalDomainURI - the logical URI (only the domain part is used). * @param physicalLocation - a physical URI location * @throws java.lang.Exception */ public void mapPhysicalURI(URI logicalDomainURI,URI physicalURI) throws Exception { if(logicalDomainURI.isOpaque()) { // We do not support opaque logical URIs since they don't have a domain. throw new URISyntaxException("We support only hierarchical logical URIs","opaque"); } assert logicalDomainURI.getHost()!=null; mappings.put(logicalDomainURI.getHost(),physicalURI); } /** * * @param fullLogicalURI - the logical URI (only the domain part is used). * @return the physical URI * @throws java.lang.Exception */ public URI getPhysicalURI(URI fullLogicalURI) throws Exception { assert fullLogicalURI.getHost()!=null; return (URI)mappings.get(fullLogicalURI.getHost()); } protected MapperImpl() { } }

3.6 Discovery The discovery component will be available as a web service that exposes a single interface – Discovery.


9

3.6.1 Interfaces The discovery web service exposes two operations – DiscoverRankedServices and DiscoverRankedServiceUrls. The first takes a WSMO goal and returns a ranked list of web services represented by their semantic service descriptions. The second takes again a WSMO goal and returns a ranked list of URLs to the semantic descriptions of the services. The schema types of the goal, ranking and service descriptions are still work in progress.

Listing 1: Discovery web service WSDL description <definitions name="DiscoveryService" targetNamespace= "http://www.dip.semanticweb.org/discovery/DiscoveryService.wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.dip.semanticweb.org/discovery//DiscoveryService.wsdl" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd2= "http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> Describes a WSDL interface for DIP semantic discovery service </documentation> <types> <xsd:schema targetNamespace= "http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd2= "http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2"> <xsd:complexType name="RankedUrl"> <xsd:annotation> <xsd:documentation> URL to a Web Service Description ranked by the discovery service </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="url" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="1" name="ranking" type="xsd2:ToBeSpecified"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="RankedService"> <xsd:annotation> <xsd:documentation>A Web Service Description ranked by the discovery service </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="serviceDescription" type="xsd2:ToBeSpecified"/> <xsd:element maxOccurs="1" minOccurs="1" name="ranking"


10

type="xsd2:ToBeSpecified"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Query"> <xsd:annotation> <xsd:documentation> Query containing a goal to be send to the discovery service. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="goal" type="xsd2:ToBeSpecified"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="RankedServiceList"> <xsd:annotation> <xsd:documentation> A list of ranked services discovered by the discovery Service </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="rankedService" type="xsd2:RankedService"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ToBeSpecified"> <xsd:annotation> <xsd:documentation> IMPORTANT: This type is used whenever further specification is required. </xsd:documentation> </xsd:annotation> </xsd:complexType> <xsd:complexType name="RankedUrlList"> <xsd:annotation> <xsd:documentation> List of ranked Urls discovered by the discovery service. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="rankedUrl" type="xsd2:RankedUrl"/> </xsd:sequence> </xsd:complexType> </xsd:schema> </types> <message name="DiscoverRankedUrlsRequest"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> InMessage for the DiscoverRankedServiceUrls operation </documentation> <part element="xsd2:Query" name="query"/> </message> <message name="DiscoverRankedServicesRequest"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> InMessage for the DiscoverRankedServices operation </documentation> <part element="xsd2:Query" name="query"/> </message>


11

<message name="DiscoverRankedUrlsResponse"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> OutMessage for the DiscoverRankedServiceUrls operation </documentation> <part element="xsd2:RankedUrlList" name="result"/> </message> <message name="DiscoverRankedServicesResponse"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> OutMessage for the DiscoverRankedServices operation </documentation> <part element="xsd2:RankedServiceList" name="result"/> </message> <portType name="DiscoveryServicePortType"> <operation name="DiscoverRankedServices"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> Takes a query containing a goal and returns a ranked list of discovered Web Service Descriptions </documentation> <input message="tns:DiscoverRankedServicesRequest"/> <output message="tns:DiscoverRankedServicesResponse"/> </operation> <operation name="DiscoverRankedServiceUrls"> <documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> Takes a query containing a goal and returns a ranked list of URLs to the discovered Web Service Descriptions </documentation> <input message="tns:DiscoverRankedUrlsRequest"/> <output message="tns:DiscoverRankedUrlsResponse"/> </operation> </portType> <binding name="DiscoveryServiceBinding" type="tns:DiscoveryServicePortType"> <binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="DiscoverRankedServices"> <operation soapAction= "capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServices" style="document"/> <input> <body use="literal"/> </input> <output> <body use="literal"/> </output> </operation> <operation name="DiscoverRankedServiceUrls"> <operation soapAction= "capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServiceUrls" style="document"/> <input> <body use="literal"/> </input> <output> <body use="literal"/> </output> </operation> </binding> <service name="DiscoveryService"> <port binding="tns:DiscoveryServiceBinding" name="DiscoveryServicePort"> <address location="http://localhost:8000/ccx/DiscoveryService"/> </port> </service>


12

</definitions>

3.7 Invocation The invocation component is implemented as a Java interface called Invoker that exposes a single method called invoke: invoke(WebService webService, WSMLDocument document): InvokerResult

3.8 Mediation (Data) Deliverable D5.2 of DIP, [7], was meant to provide a specification for mediation module for data mediation. What it actually includes in its final version can be summarized as follows: (i) definition of the data-mediation task and its context; (ii) description a possible mediation approach; (iii) references to already specified components; (iv) high-level specification for the missing components; and (v) a concrete proposal for generation of the syntactic transformation scripts from ontology mappings. The data-mediation is performed by an ooMediator, which can transform a message (or other set of instance data) between two WSML ontologies. Although different implementations of ooMediators are possible, the concrete approach proposed in [7] counts on universal mediation services, which can mediate between arbitrary ontologies, based on an ontology mapping between them, which are specified in the language developed in SEKT, [3]. The ooMediator is a profile, which specifies the ontologies (source and target), the ontology mapping, the mediation service and the transformation procedure (optional). Two major cases are distinguished:

• Semantic mediation, performed by an universal Semantic Transformation Service (SETS), which operates either directly with the ontology mapping or with a sort of “compiled” executable transformation specification. It is envisaged that the SETS will, likely, use a rule execution engine (REE), which on itself bears reasoning capabilities.

• Syntactic mediation, performed by a universal Syntactic Transformation Service (SYTS), which operates either directly with the ontology mapping or with a pre-compiled syntactic transformation procedure. The applicability of the syntactic procedure is limited, because in the general case, purely syntactic transformation between two ontologies is impossible. Thus, the applicability of the syntactic procedure is decided through an evaluation of the ontology mapping. A concrete procedure for generation of XSLT scripts from ontology mappings is specified in [7].

The overall interaction of the components related to the setup of an ooMediator, according to the proposed approach for data mediation, is presented on Figure 2. The interfaces of the involved components are presented in sub-section 3.8.1 below. Ontology mappings are created with an Ontology Mapping Tool and than stored in an Ontology Mapping Store. There is no need for specification of component interfaces for the mapping tool, as far as it is not being invoked from other components (it is rather used by a human user). The Ontology Mapping Store interfaces (together with a number of other related interfaces) are specified in [1] and summarized in Appendix B of [7].


13

Due to there large volume and partial relevance to the data-mediation we are not going to copy them here.

Figure 2. Interaction diagram for the development of ooMediator for data-mediation

Run-time the mediation process is determined by the WSMO execution environment, which decides whether and how the ooMediators are to be used. A possible example of the latter is given in section 5.2 of [5]. The concrete definition and binding of the mediation service is also determined by the execution environment.

3.8.1 Interfaces Semi-formal specifications of the components presented at Figure 2 are given in Error! Reference source not found. below. It does not cover the components commented and excluded at the end of the preceding paragraphs. The interface descriptions consist of a Java-like method specification(s) and an information comment.

Table 1. Interfaces for Data Mediation-Related Components

Component Interface Description

SYTS Applicability Checker

Boolean check(MappingID id)

Checks whether a correct syntactic transformation can be derived from a particular ontology mapping.

Semantic Transformation

SemTransfSpec generate(MappingID mapping)

A sort of a compiler of ontology mappings, which produces

look-up use

refer mediation service

use

refer mediation service

store use indirectly

store

use

MediationLibrary

Ontology Mapping

Tool

Syntactic Transformation

Generator

Semantic Transformation

Generator

Create Ontology Mapping

Create Syntactic

ooMediator

SYTS Applicability

Checker

Ontology Mapping

Store

Check SYTS

Applicability

Generate SETS Spec.

Generate SYTS Spec.

Store and Publish

ooMediator

SETS:Semantic Transformation

Service

SYTS: Syntactic Transformation

Service

Create Syntactic

ooMediator


14

Generator executable rules, as discussed in [1]. The specification format depends on the REE.

Syntactic Transformation Generator

SyntTransfSpec generate(MappingID mapping)

A sort of a compiler of ontology mappings, which produces syntactic transformation rules. A specification of such a component that produces XSLT scripts is provided in section 5 of [7].

Syntactic Transformation Service (SYTS)

Instance mediate(SyntTransfSpec spec, Instance id)

A web service, which should be specified accordingly; here we only offer an idea of the input and the output.

Semantic Transformation Service (SETS)

Instance mediate(SemTransfSpec spec, Instance id)

A web service, which should be specified accordingly; here we only offer an idea of the input and the output.

Mediation Library

MeadiatorList lookup(Ontology source, Ontology target)

A mediator library, which allows for storage, retrieval, and lookup of mediators. In terms of Java API, the parameters should comply with the WSMO API, [4]. Such a component, including more advanced features as well, is scheduled for development within deliverable D5.6 of DIP. Basic support for the lookup of mediators should also be provided through the Resource Manager (see section 3.5).

Rule Execution Engine (REE)

Instance transform(SemTransfSpec spec, Instance id)

This engine can be expected to use a WSML reasoner. Many of the transformations can be regarded as, or transformed into, specific reasoning tasks. The formal language, which the mapping language is grounded to, might pose some restrictions on the use of several constructs of the mapping language, because such constructs are beyond the expressive power of the formal language. Within SEKT, it is envisaged that REE uses an instance unification component – see the InstanceTransformation and InstanceUnification interfaces in Appendix B of [7]. However, in the general data-mediation context considered in DIP, unification is not applicable, because it requires mediation that is bound to the recipient.


15

3.9 Semantic Repository To meet the diverse requirements towards it, the Semantic Repository component of DIP is specified as a part of the Ontology Management System (OMS), which is developed in the Ontology Management Working Group (http://www.omwg.org). OMS is build around an implementation of the Ontology Representation and Data Integration (ORDI) conceptual framework, presented in D2.2, [8]. The ORDI implementation, in itself, is based on the ontology representation package of the WSMO API, presented in deliverable D6.4, [4], and section 4.1 here. This comprehensive dependency schema (see Figure 3)was invented in order to make sure that, “by design”, the web-service related tools (WSMO Studio) and the OMS are interoperable. Further, it assures that all the tools based on these interfaces will be able to use various reasoning and repository implementations, compliant to them.

Figure 3. Semantic Repository-Related Interfaces

The interfaces for the Semantic Repository will be defined in detail within the ORDI implementation. Its main features can be specified as follows:

• To extend the org.wsmo.IO sub-packages of the WSMO API with further interfaces, supporting behaviors and use cases necessary in ontology management and data integration. Whenever necessary, the interfaces specified in the www.omwg.Ontology and org.wsmo.Common packages will also be extended.

• Implementations of the IO.Parser interface3 for (parsing of and serialization to) different syntaxes and languages will be provided. The first candidates in this

3 Version “rc1” of the API is referred here. In later versions the IP package got divided into sub-packages, so the Parser interface is now part of the IO.parser package; similarly the Datastore interface went into the IO.datastore package.

WSMO Studio SWS Integrated Development

Environment

WSMO4JReference Implementation

WSMO APIInterface Definitions

Ontology

Ontology Management Suite

ORDI Ontology Representation

& Data Integration

Repository (Sesame,

YARS)

Reasoner (KAON2)

Other Data-

sources


16

direction are the RDF/XML syntax for RDFS and OWL and the XML WSML Syntax.

• Wrappers of the different semantic repositories will be developed as implementations of the IO.Datastore interface (and its extensions in ORDI). The first candidates in this direction are Sesame, http://www.openrdf.org, and KAON 2, [10]. The later is the reasoner developed within WP1, D1.2 and others. Sesame is one of the most popular, and probably the most efficient, RDF repository, which got extended recently with a partial OWL Lite support. YARS is a high-performance distributed semantic repository which will be further extended and delivered as D2.5 of DIP. YARS fits in the Sesame architecture as a specific storage and inference layer; thus, the Sesame wrapper will meet a number of goals:

o integration of YARS; o access to a number of other storage and inference implementations,

ranging from point-and-click in-memory packages to MySQL and ORACLE-based ones;

o access to a mature RDFS infrastructure with support for a number of syntaxes (XML, N-Triples, N3) and query languages (SeRQL, RDQL, RQL).

Up until this phase of the project, the efforts were concentrated into development of the WSMO API, which has a very central role in DIP and several other WSMO-related projects. This delayed a bit the implementation of ORDI, which is dependent on it. As a result, ORDI implementation is still not available. The only semantic repository interface, currently defined, is org.wsmo.IO.Datastore within the WSMO API: public interface DataStore { void save (Identifiable object); Identifiable load (URIRef objectID); boolean contains (URIRef objectID); }

This interface, allows for storage and retrieval of WSMO elements of arbitrary granularity, including top-level ones (such as web services descriptions and ontologies), but also elementary ones (such as concepts and attributes).

3.10 Web Service Registry As mentioned above, the approach underlying the WS registry definition within D4.2 is currently under discussion within the project. There is an alternative strategy for registration and publishing based on a semantic store. This section below refers mostly to D4.2, [6], but it should be considered that in the course of the project these interface definitions could be updated.

3.10.1 Interfaces The interfaces of the two web services that offer the public API of the DIP registry are documented respectively in chapters 4.2 and 4.3 of D4.2, . We will provide here a brief overview of them.


17

3.10.1.1 Publishing Interface The operations dipPublishService, dipPublishMediatorService, dipPublishOntology, and dipPublishGoal take as parameters the business entity that owns the element (string), the set of non-functional properties that will be mapped to UDDI (set of strings), the URI of the WSML document that represents the element and an authentication token. In addition the dipPublishService and dipPublishMediatorService operations take the WSDL of the corresponding web service that is being stored (It seems this is not needed – at the moment the WSML description for web services includes the grounding of the service, have to make a comment to D4.2). All of the four operations return the registry generated key of the element. All the four operations may compile/store the WSML description locally or just verify it and store a link to it. There are four corresponding operations for deleting DIP elements stored in the registry: dipDeleteService, dipDeleteMediatorService, dipDeleteOntology and dipDeleteGoal. These take as a parameter the key returned from the corrseponding publish operation and again an authentication token. 3.10.1.2 Retrieval Interface There are four operations in this interface: dipRetrieveService, dipRetrieveMediatorService, dipRetrieveOntology and dipRetrieveGoal. All of those need two parameters – a find query type (AND, OR, LIKE) and the text of the query. The text should obey the UDDI query syntax and roughly speaking consists of key value pairs. The keys are the DIP element properties and the publisher information listed in the Publishing Interface in chapter 3.10.1.1 of D4.2. The find query type might be missing, AND is assumed in that case. All the functions return a list of the corresponding type (retrieveServiceResultType for service and mediator service, retrieveOntologyResultType for ontologies, and retrieveGoalResultType for goals). Each of the elements of the list contains the set of non-functional properties and the URI of the WSML description. The retrieveServiceResultType type contains also the WSDL of the corresponding service.

3.10.2 Usage examples The Java code fragments below provide examples of using the DIP registry API through Apache WSIF. The first example is publishing an ontology to the registry, the ontology is the date/time example ontology bundled with the WSMX environment. package org.semanticweb.dip.examples.Registry; import org.apache.wsif.util.*; import javax.wsdl.*; import org.apache.wsif.*; import java.util.Iterator; import java.util.Hashtable; import javax.xml.namespace.QName; public class Publishing { public static void main(String[] args) { try { Definition def = WSIFUtils.getDefinitionFromLocation(

"file:///C:/publish/","publish.wsdl"); // Create WSIFService object using WSIFServiceFactory with


18

// WSDL definition as parameter. WSIFServiceFactory factory=WSIFServiceFactory.newInstance(); WSIFService serv = factory.getService(def); // Map the complex dipElementPropertiesAbstractType xsd type // to a java class // implementation serv.mapType( new QName("urn:dip-org:publish_v1", "dipElementPropertiesAbstractType"), Class.forName( "org.dip.ws.dipElementPropertiesAbstractType")); // Create WSIFPort using WSIFService object with port name // as parameter. WSIFPort port = serv.getPort("PublishPort"); // Create WSIFOperation using WSIFPort with operation, // input and output names as parameters. WSIFOperation op = port.createOperation("dipPublishOntology", "publishOntologyDescription", "publishOntologyKey"); // Create container for the input message WSIFMessage input = op.createInputMessage(); // Create container for the output message WSIFMessage output = op.createOutputMessage(); // Create container for the fault message WSIFMessage fault = op.createFaultMessage(); // Set parameter values for the input message, e.g., Hashtable inputParts=new Hashtable(); inputParts.put("authToken","{2C3E7212-D130-45C0-B250-57EC7AB3AF84}"); inputParts.put("serviceKey","{FFCD4A9A-89E5-48AE-AD00-895279CE906F}"); inputParts.put("businessEntity","DERI International"); org.dip.ws.dipElementPropertiesAbstractType descr= new org.dip.ws.dipElementPropertiesAbstractType(); descr.setPublisher("DERI International"); descr.setCreator("DERI International"); descr.setDescription( "generic representation of data and time including basic algebra"); descr.setTitle("Date and Time Ontology ontology"); descr.setDate("2004-07-06"); descr.setFormat("text/plain"); descr.setCoverage("World"); descr.setLanguage("en-US"); descr.setRelation("http://www.isi.edu/~pan/damltime/time-entry.owl, http://www.w3.org/TR/xmlschema-2/"); descr.setSubject("Date, Time, Date and Time Algebra"); inputParts.put("descr",descr); inputParts.put("wnfp", "http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml"); input.setParts(inputParts); // Execute operation boolean success = op.executeRequestResponseOperation( input, output, fault); WSIFMessage toUse=fault; if(success) { toUse=output; } Iterator parts=toUse.getParts(); while(parts.hasNext()) { System.out.println(parts.next()); } } catch(Exception ex) {ex.printStackTrace();} } }

The second example retrieves from the registry all ontologies published by DERI.


19

package org.semanticweb.dip.examples.Registry; import org.apache.wsif.util.*; import javax.wsdl.*; import org.apache.wsif.*; import java.util.Iterator; import java.util.Hashtable; import javax.xml.namespace.QName; public class Retrieval { public static void main(String[] args) { try { Definition def = WSIFUtils.getDefinitionFromLocation( "file:///C:/publish/","retrieve.wsdl"); // Create WSIFService object using WSIFServiceFactory with // WSDL definition as parameter. WSIFServiceFactory factory=WSIFServiceFactory.newInstance(); WSIFService serv = factory.getService(def); // Map the complex retrieveOntologyResultType xsd type to a java class // implementation serv.mapType( new QName("urn:dip-org:retrieve_v1", "retrieveOntologyResultListType"), Class.forName( "org.dip.ws.retrieveOntologyResultListType")); serv.mapType( new QName("urn:dip-org:retrieve_v1", "RetrieveOntologyResultType"), Class.forName( "org.dip.ws.RetrieveOntologyResultType")); // Map the complex dipElementPropertiesAbstractType xsd type // to a java class // implementation serv.mapType( new QName("urn:dip-org:retrieve_v1", "dipElementPropertiesAbstractType"), Class.forName( "org.dip.ws.dipElementPropertiesAbstractType")); // Create WSIFPort using WSIFService object with port name // as parameter. WSIFPort port = serv.getPort("RetrievePort"); // Create WSIFOperation using WSIFPort with operation, // input and output names as parameters. WSIFOperation op = port.createOperation("dipRetrieveOntology", "QueryDipElements", "retrieveOntologyResultList"); // Create container for the input message WSIFMessage input = op.createInputMessage(); // Create container for the output message WSIFMessage output = op.createOutputMessage(); // Create container for the fault message WSIFMessage fault = op.createFaultMessage(); // Set parameter values for the input message, e.g., Hashtable inputParts=new Hashtable(); inputParts.put("authToken","{2C3E7212-D130-45C0-B250-57EC7AB3AF84}"); inputParts.put("dipFindOrLikeQualifier","AND"); inputParts.put("retrieveQuery","{creator=DERI International}"); input.setParts(inputParts); // Execute operation boolean success = op.executeRequestResponseOperation(input, output, fault); if(!success) { Iterator parts=fault.getParts(); while(parts.hasNext()) { System.out.println(parts.next()); } } else { org.dip.ws.retrieveOntologyResultListType ontologies =


20

(org.dip.ws.retrieveOntologyResultListType)output.getObjectPart( "tns:retrieveOntologyResultListBody"); org.dip.ws.RetrieveOntologyResultType[] ontologyArr= ontologies.getRetrieveOntologyResultList(); for(int i=0;ontologyArr!=null && i<ontologyArr.length;i++) { org.dip.ws.RetrieveOntologyResultType ontology=ontologyArr[i]; System.out.println(ontology.getWnfp()+", creator: "+ontology.getDipElementPropertiesAbstract().getCreator()); } } } catch(Exception ex) {ex.printStackTrace();} } }


21

3.11 Choreography and Orchestration The ORCA component is under development at the moment within WSMX, [15]. It will be implemented as a Java component; below we present the preliminary version of the API of the component.

3.11.1 Interfaces The interface of the choreography engine is defined as follows: public interface ChoreographyEngine { private Choreography loadChoreography(ID id); private ID getID(ID id); public void send(Message message, ID id); public void receive(Message message, ID id); }


22

4 Additional Common APIs In addition to the component APIs, there are also a number of other, in a sense lower-level, interfaces which are important for the interoperability across the tools and components in DIP.

4.1 WSMO API and Reference Implementation The WSMO API, [4], is a set of programming interfaces, whose main function is to provide a Java binding for the WSMO semantic web services framework, [14]. The structure of the API is depicted in Figure 4, where the dependency between the modules (Java packages) goes from the bottom to the top.

Figure 4. WSMO API and WSMO4J

Here follows a brief enumeration and short description of the packages:

• Common: the most general primitives, e.g.: identifiers, literals, variables, and non-functional properties.

• IO: input and output related interfaces, namely:

• Parser: taking care of parsing from or serialization to a particular syntax;

• Datastore: defining the basic store and load interfaces, see section 3.9. • Locator: interfaces that allow physical locators to be mapped to logical

identifiers in a flexible manner. • Ontology: contains ontology-specific interfaces (ontologies, concepts, instances,

relations, axioms, logical expressions, etc.) This package represents the bridge to

WSMO Studio SWS Integrated Development

Environment

Ontology Management Suite

WSMO APIInterface Definitions

WSMO4JReference Implementation

Common & IO

Ontology

Goal Service

Mediator

In-memory Structures

File Datastore

WSML Parser

ORDI Ontology Representation

& Data Integration

Reasoner Wrappers

Import/Export Parsers

Repository Wrappers

Data Integration

Versioning

Mediation

Editing and Browsing


23

ORDI and the ontology management tools developed within the Ontology Management Working Group (http://www.omwg.org). For this reason, the package namespace is org.omwg.ontology.*, in contrast to the other packages of the WSMO API, whose names start with org.wsmo.*.

• Goal, Service, Mediator: interfaces modelling the corresponding primitives in WSMO. These are all dependent on Common, IO, and Ontology packages.

WSMO API is a purely abstract set of interfaces. It means that other programs may not use it directly – they could only use a particular implementation of these interfaces. WSMO4J is a reference implementation of the WSMO API, which allows its usage without any further development. WSMO4J includes:

• Implementations of the primitive-modelling interfaces from the Ontology, Goal, Service, and Mediator packages (e.g. concept, instance, goal, service).

• Implementation of the Parser interface (parsing and serialization) with respect to the WSML human-readable syntax, [2].

• Implementation of the Datastore interface, providing persistency on top of a proprietary binary file storage.

• Implementation of the Locator interface. The WSMO API and WSMO4J are open-source, available together at the wsmo4j SourceForge project, having its home page at http://wsmo4j.sourceforge.net/. Documentation of the API is available there as a JavaDoc reference, as well as a programmers guide, [4].

4.2 Ontology Management Tools The different ontology management tools (apart from the semantic repository) are not first-class citizens of the DIP architecture, as long as those are not directly involved in web service execution. Still, it is the case that some of them could fit as components into customized web-service development environments. Those are discussed in a bit more detail in D6.4, [4] – here we only mention their existence. The ontology management tools of DIP (WP2) are developed as part of the work of OMWG. The roadmap of the group determines that an integrated extensible Ontology Management System will be implemented on the basis of the Eclipse4 framework, version 3.0. The particular tools are developed as separate plug-ins, which interoperate through shared data models. The same approach (Eclipse-based architecture) is agreed for the design of a semantic web services development environment, named WSMO Studio. It will include a number of plug-ins, amongst which WSMO browser and editor. As presented in Figure 4, WSMO Studio and the OMS will both use the WSMO API (section 4.1). The later together with Eclipse, provides sufficient ground for interoperability, even though, the two environments will be developed independently.

4 http://www.eclipse.org/


24

5 CONCLUSION This deliverable provided a roadmap towards the programming interfaces of the various components of the DIP architecture. For many components, the interfaces are still not specified in detail due to the fact that the corresponding aspects of the conceptual framework are not finalized yet. Further, the level of granularity of the presented interfaces is still quite diverse – this could be explained with the early stage of the development of the architecture. While this was an expected situation the project plan envisions an update of the APIs to be presented in deliverable D6.9 “Revision of the components APIs”. It is the understanding of the authors that the currently existing APIs provide sufficient level of determinism to allow for a reasonably smooth software development in the middle phase of the project. Finally, Table 2 provides a summary of the interfaces for the different components. Due to time constraints the table is not verified with the each of the component (interface) developers.

Table 2. Component Interfaces Summary

Component Interface Type

Status Related Deliverables

Due

Communica-tion Manager

Web Service

Under development

WSMX first version ready

Execution Manager

EJB Under development


Event Manager Java API Under development


Resource Manager

Java API Under development


Discovery Web Service

Very early work on the specification

D4.8 – specification; D4.14 – prototype;

M24 M30

Invocation Java API The specification is ready

D4.6 – specification; D4.7 – prototype.

M12 M18

Data Mediation

Java APIs Early work on the spec. Initial version of the Ontology Mapping APIs is ready.

D5.2 – specification; D5.4 – prototype v1.

M12 M18

Semantic Repository

Java API Initial version of the API, as part of

D2.3 – ontology representation and

M18


25

wsmo4j data integration (ORDI) framework; D2.5 – semantic repository.

Service Registry

Web Service

Ready, but revisions are already being discussed

D4.2 – publishing process specification; D4.3 – publishing process development.

M6 M18


26

REFERENCES [1] Atanasov, S; Manov, D. (2004). Ontology Mapping Pattern Store Specification.

Annex1 to SEKT project deliverable D4.5.1 „Report on Ontology mediation as service component“. http://sekt.semanticweb.org.

[2] de Bruijn, J; Foxvog, D; Lausen, H; Oren, E; Roman, D; Fensel, D. (2004). The WSML Family of Representation Languages. WSML deliverable D16.1v0.2, 24.12.2004, http://www.wsmo.org/2004/d16/v0.2/.

[3] de Bruijn, J; Foxvog, D; Zimmermann, K. (2004). D4.3.1: Ontology Mediation Patterns Library. SEKT project deliverable. http://sekt.semanticweb.org/.

[4] Dimitrov, M; Ognyanov, D; Kiryakov, A. (2005). D6.4: WSMO API. DIP project deliverable, http://dip.semanticweb.org. Documentation of WSMO4J, http://wsmo4j.sourceforge.net/.

[5] Hauswirth, M; Schmidt, R; Altenhofen, M; Drumm, C; Bussler, C; Moran, M; Zaremba, M; Vasiliu, L; Quantz, J; Henocque, L; Haller, A; Sakpota, B; Kilgariff, E; Petkov, S; Aiken, D; Oren, E; Ohlendorf, M; Mocan, A. (2004). D6.2: DIP Arhictecture. DIP Project, WP6 Interoperability and Architecture. http://dip.semanticweb.org.

[6] Herzog, R; Zugmann, P; Quantz, J. (2004). D4.2: Publishing Process Specification. DIP project deliverable. http://dip.semanticweb.org.

[7] Kiryakov, A; Drumm, C; Al-Jadir, L; Boukottaya, A; Kilgarriff, E; Quantz, J. (2005). D5.2: Mediation Module Specification: Business Data-Level Mediation. DIP project deliverable. http://dip.semanticweb.org.

[8] Kiryakov, A; Ognyanov, D; Kirov, V. (2004) D2.2: An Ontology Representation and Data Integration (ORDI) Framework. DIP project deliverable. http://dip.semanticweb.org.

[9] Mocan, A; Cimpian E. (2004). WSMX Mediation, (WSMO Working Draft), version 0.1; http://www.wsmo.org/2004/d13/d13.3/v0.1/.

[10] Motik, B; Nagypal, G. (2004). D1.2: Prototype of the ontology based query parser and engine. DIP project deliverable. http://dip.semanticweb.org.

[11] Oren, E. (2004). WSMX Execution Semantics (WSMO Working Draft), version 0.1; http://www.wsmo.org/2004/d13/d13.2/v0.1/.

[12] Paolucci, M; Kawamura, T; Payne T. R; Sycara, K. (2002). Semantic Matching of Web Services Capabilities. In Proceedings of the 1st International Semantic Web Conference (ISWC 2002).

[13] Preist, C; Roman, D. – editors. (2004). D12v0.1. Web Service Modeling Ontology - Full (WSMO-Full). WSMO Working Draft 24 June 2004. http://www.wsmo.org/2004/d12/v0.1/20040719/ .

[14] Roman, D; Lausen, H; Keller, U. – editors; Oren, E; Bussler, C; Kifer, M; Fensel, D. (2004). Web Service Modeling Ontology (WSMO). WSMO deliverable D2 V1.0, working draft, 20 Sept 2004. http://www.wsmo.org/2004/d2/v1.0/.

[15] Zaremba, M; Moran, M; Cimpian, E; Mocan, A; Oren, E – editors. (2004). WSMX Implementation (WSMO Working Draft), version 0.1; http://www.wsmo.org/2004/d13/d13.5/v0.1/.

fp6 - 507483(api) of the components provided in the dip architecture document (d6.2, [5]). there is...

Documents