D6.3 DIP component APIs

whooshribbitSoftware and s/w Development

Dec 2, 2013 (3 years and 6 months ago)

100 views




DIP

Data, Information and Process Integration with Semantic Web Services

FP6
-

507483





Deliverable



D6.3

DIP component APIs




Vesselin Kirov

Atanas Kiryakov


02 December 2013





DIP component APIs


Deliverable 6.3



1

1

E
XECUTIVE
S
UMMARY

This deliverable prov
ides an overview of the application programming interfaces (API)
of the components provided in the DIP architecture document (D6.2). The level of
granularity and maturity of the specification of the different interfaces varies across the
components. For so
me 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 conce
ptual framework or the architecture. Whenever
possible, this deliverable provides examples of how to use these components to
integrate the whole DIP execution environment.

This deliverable takes input from number of places: (i) the DIP Architecture, D6.2;
(ii)
the different component specifications developed within workpackages WP1, WP2,
WP4, and WP5 and (iii) WSMX execution environment, which provides interface
specifications, not available elsewhere. The interfaces, defined here should be of
interest to t
he use
-
case partners and to technology providers which
develop components

implementations.

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


Status


Version. 0.1


Nature

Prototype


Report


Dissemination



Dissemination
Level

Public


Consortium





Authors (Partner)

Vesselin Kirov (Sirma)

Responsible
Author

Vesselin Kirov

Email

veskok@sirma.bg

Partner

SIRMA

Ph
one

+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



DIP component APIs


Deliverable 6.3



3

Project
Consortium
I
nformation

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:

chris.bussler@deri.org

Tel: +353 91
512
460


Fundacion De La

Innovacion.Bankinter

Bankinter



Monica Martinez Montes

Fundacion de la Innovation.
BankInter

Paseo Castellana, 29

28046 Madrid,

Spain

Email:

mmtnez@bankinter.es


Tel:
916234238

Berlecon

Research GmbH

Berlecon


Dr. Thorsten Wichmann

Berlecon Research GmbH

Oranienburger Str. 32

10117 Berlin,

Germany

Email:
tw@berlecon.de

Tel: +49 30
2852960

British Telecommunications Plc.

BT


Dr John Davies

BT Exact (Orion Floor 5 pp12)

Adastral Park Martlesham

I
pswich IP5 3RE,

United Kingdom

Email:
john.nj.davies@bt.com

Tel: +44 1473 609583

Swiss Fede
ral Institute of Technology,
Lausanne

EPFL


Prof. Karl Aberer

Distri
buted Information Systems Laboratory

É
cole Polytechnique Féderale de Lausanne

Bât. PSE
-
A

1015 Lausanne, Switzerland

Email

:
Karl.Aberer@epfl.ch

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:
maryr@essexcc.gov.uk

Tel:
+44 (0)124
5 436524

Forschungszentrum Informatik

FZI




Andreas Abecker

Forschungszentrum Informatik

Haid
-
und
-
Neu Strasse 10
-
14

76131 Karlsruhe

Germany

Email:
abecker@fzi.de

Tel:
+49 721 9654
0

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

UIBK

Prof. Dieter Fensel


DIP component APIs


Deliverable 6.3



4



Institute of computer science

University of Innsbruck

Technikerstr. 25

A
-
6020 Innsbruck, Austria

Email:
dieter.fensel@deri.org


Tel:
+43 512 5076485

ILOG SA

ILOG


Christian de Sainte Marie

9 Rue de Verdun, 94253

Gentilly, France

Email:
csma@ilog.fr

Tel:
+33 1 49082981

inubit AG

Inubit


Torsten Schmale

inubit AG

Lützowstraße 105
-
106

D
-
10785 Berlin

Germany

Email:
ts@inubit.com

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:
rbenjamins@isoco.com

Tel. +34 913 349 797

The Open University

OU


Dr. John Domingue

Knowledge Media Institute

The Open University,

Walton Hall


Milton Keynes, M
K7 6AA

United Kingdom

Email:

j.b.domingue@open.ac.uk


Tel.: +
44 1908 655014

SAP AG

SAP


Dr. Elmar Dorner

SAP Research, CEC Karlsruhe

SAP AG

Vincenz
-
Priessnitz
-
Str. 1

76131 Karlsruhe, Germ
any

Email:
elmar.dorner@sap.com

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
:
atanas.kiryakov@sirma.bg


Tel.:
+359 2 9768 303

Tiscali Österreich Gmb
h


Tiscali



Dieter Haacker


Tiscali
Österreich

GmbH.

Diefenbachgasse 35

A
-
1150 Vienna

Austria

Email
:
Dieter.Haacker@at.tiscali.com

Tel:
+43 1
899 33 160

Unicorn Solution Ltd.

Unicorn

Jeff Eisenberg


DIP component APIs


Deliverable 6.3



5


Unicorn Solutions Ltd,

Malcha Technology Park 1

Jerusalem 96951

Israel

Email:
Jeff
.Eisenberg@unicorn.com

Tel.
:
+972 2
6491111

Vrije Universiteit Brussel

VUB


Carlo Wouters

Starlab
-

VUB

Vrije Universiteit Brussel

Pleinlaan 2, G
-
10

1050

Brussel
,
Belgium

Email:
carlo.wouters@vub.ac.be

Tel.
:
+32 (0) 2 629 3719



DIP component APIs


Deliverable 6.3



6

2

T
ABLE OF
C
ONTENTS


1

E
XECUTIVE
S
UMMARY

................................
................................
..............................

I

2

T
ABLE OF
C
ONTENTS

................................
................................
..............................

VI

3

I
NTRODUCTION

................................
................................
................................
........

1

4

E
XPOSED FUNCTIONALITI
ES OF THE
DIP

C
OMPONENTS

................................
........

2

4.1

Communication Manager

................................
................................
.................

2

4.2

Execution Manager

................................
................................
...........................

2

4.3

Event Listeners

................................
................................
................................
.

2

4.4

Event Manager

................................
................................
................................
..

2

4.5

Resource Manager

................................
................................
............................

2

4.6

Discovery

................................
................................
................................
..........

3

4.7

Invocation

................................
................................
................................
.........

3

4.8

Mediation (Data)
................................
................................
...............................

3

4.9

Semantic Repository

................................
................................
.........................

3

4.10

Service Registry

................................
................................
................................

5

4.10.1

Publishing

................................
................................
................................
.

5

4.10.2

Retrieval

................................
................................
................................
...

5

4.11

Choreography and Orchestration (ORCA)

................................
.......................

5

5

DIP

C
OMPONENT
API
S

................................
................................
...........................

5

5.1

Communication Manager

................................
................................
.................

5

5.2

Execution Manager

................................
................................
...........................

6

5.3

Event Listeners

................................
................................
................................
.

6

5.3.1

Interfaces

................................
................................
................................
..

6

5.4

Event Manager

................................
................................
................................
..

6

5.5

Resource Manager

................................
................................
............................

6

5.5.1

Interfaces

................................
................................
................................
..

7

5.5.2

Examples

................................
................................
................................
..

7

5.6

Discovery

................................
................................
................................
..........

8

5.6.1

Interfaces

................................
................................
................................
..

8

5.7

Invocation

................................
................................
................................
.......

11

5.8

Mediation (Data)
................................
................................
.............................

11

5.8.1

Interfaces

................................
................................
................................

11

5.8.2

Usage examples

................................
................................
......................

11

5.9

Semantic Repository

................................
................................
.......................

12

5.10

Web Service Registry

................................
................................
.....................

13


DIP component APIs


Deliverable 6.3



7

5.10.1

Interfaces

................................
................................
................................

13

5.10.2

Usage examples

................................
................................
......................

14

5.11

Choreography and Orchestration

................................
................................
....

17

5.11.1

Interfaces

................................
................................
................................

17

6

A
DDITIONAL COMMON
API
S

................................
................................
.................

18

6.1

WSMO API and Reference Implementation

................................
..................

18

6.2

Ontology Management Tools

................................
................................
.........

19

7

C
ONCLUSION

................................
................................
................................
..........

20

8

R
EFERENCES

................................
................................
................................
..........

21


FP6


504083

Deliverable 6.3





1

3

I
NTRODUCTION

This deliverable
provides an overview of
the applicat
ion programming interfaces

(API)

of the components provided in the DIP architecture document (D6.2)
. The level of
granularity and maturity of the specification of the different interfaces varies across the
components. For some of them, there are fully
-
oper
ational 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 architect
ure. Whenever
possible, this deliverable
provides examples of how to use these components to
integrate the whole DIP execution environment.

This document is structured as follows: Section
4

contains the descriptions of the
funct
ionalities exposed in each of the components in the DIP architecture; Section
5

presents the APIs of the components plus usage examples; Section 6 describes
interfaces of components which are not part of the execution environmen
t architecture,
but still appear to be relevant to integration of the different software developed within
DIP
.

This document contains a considerable volume of source
-
code listings integrated within
the corresponding sections of its main body. Although the
good
-
looking

layout requires
th
e

listings
to be

provided as annexes, this is not appropriate in this case, as long, as
those represent a
n

essential part of its content.

This deliverable takes input from number of places: (i) the DIP Architecture, D6.2; (ii
)
the different component specifications developed within workpackages WP1, WP2,
WP4, and WP5 and (i
ii) WSMX execution environment, which provides interface
specifications, not available elsewhere. The interfaces, defined here should be of
interest to the
use
-
case partners and to technology providers which develop
components implementations.


FP6


504083

Deliverable 6.3





2

4

Exposed functionalities of the DIP Components

4.1

Communication Manager

The communication manager’s API is the external API for the DIP runtime
environment.

It handles t
he 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 a
dapter to convert them to WSML.

4.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
[6]

the

WSMO working group
will
maintain
a description of

the execution semantics of WMSO/DIP.

4.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 Lis
tener components that reside in the WSMX
manager

[5]
). These listeners will be responsible to process
the corr
e
s
ponding events
coming from the event manager
.

It will be the responsibility of the Execution Manager
to register eac
h 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.

4.4

Event Manager

The event manager
handl
es

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, p
lease look in
[5]
.

4.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
w
ill 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

5.5.2
) we

wi
ll
provide such an example.



FP6


504083

Deliverable 6.3





3

4.6

Discovery

In DIP when we talk about semantic discovery of web services we me
an
the
discovery
of
abstract services

[3]

represented by formal
service capabilities

[1]

which are
part of
the semantic description of the web service published in the DIP registry by the
provider.

T
h
e requesters
on their part
use a
goal description

to describe their service
requirements.

So in general the discovery process is defined as semantically matching the goal of the
requester to all known
to the registry
services capabilities and returning all

abstract
services that match the goal ranked

by a matching score similar to the one described in
[4]

4.7

Invocation

The DIP execution environment will implement two distinct types of Web Service
invocations.

Whenever the choreograp
hy/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 se
rvice 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 s
ervice to be
available with the semantic web service description. In the future versions WSMO will
provide grounding directly f
rom the web service description
.

4.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, because it is composition and function are still not clarified to the
end (see section 2.4 of D6.2,
[8]
).

The b
asic 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.

4.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
descripti
ons,
instance data, etc. Within the architecture of DIP, t
here is no clear separation between
the functions of an ontology reasoner and a repository.
As outli
ned in D2.2,
[7]
, 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.

It is the case that with most of the reasoning paradi
gms there are number
inference
-
specific
tasks, e.g. satisfiability checking and realization (instance classification).

FP6


504083

Deliverable 6.3





4

However, in the
context of a semantic web services infrastructure,

the components
, not
directly involved in ontology management,

are not
expected to directly request th
e
s
e

tasks. The 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 interfac
es required. For instance, suppose there are facts
asserted saying that


<part
O
f, type, TransitiveProperty>

<Sofia, partOf, Bulgaria>

<Bulgaria, partOf, Europe>


Than suppose a query is sent to the system asking for all parts of Europe. A repository,
whic
h 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 diff
erent sorts of ontology management
tools
.
There is no doubt, that those are 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 con
text 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 demonst
rated at
Figure 1
.



Figure 1.

Interaction with Semantic Repository

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



Ontology management tools, those develo
ped 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)


FP6


504083

Deliverable 6.3





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
[9]
.

4.10

Service
Registry

This component is specified in D4.2 and provides to the other DIP components an API
that facilitates the publishing and non
-
semantic (syntactic and structural) retrieva
l 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 o
n 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.

4.10.1

Publishing

The publishing functionality of the DIP registry will be available as a web s
ervice 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 non
-
functional properties

[1]

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 D
4.2
,
chapter 4.


4.10.2

Retrieval

The retrieva
l 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
-
function
al properties that are mapped into the underlying UDDI registry; the
AND
,
OR

or
LIKE

find qua
lifiers

and wildcards (limited to the title property).

4.11

Choreography and Orchestration (ORCA)

This component implements the choreography and orchestration in the DI
P 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

t
o 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.

5

DIP
Component
APIs

5.1

Communication Manager


The APIs of the communication manager will be described in a separate deliverable
D6.4
,
[12]
,

and they’ll be seen as the main entry point of the DIP execution
environment.


FP6


504083

Deliverable 6.3





6

5.2

Execution Manager

The execut
ion 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
de
claratively 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
dyna
mically 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.

5.3

Event Listeners

Event listener

is
common name for the set of interfaces a com
ponent 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 fo
r an end
of processing event so it will know when to return the results back to the original
requester.

5.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
.

5.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 revis
ions of this document we may add an API that will enable dynamic
change of the subscription policies and the types of events.

In that case the API will expose two interfaces: the
EventFactory

interface that would
enable components to register/unregister t
ypes of events or to create events and
EventListenerFactory

that will be the one the components would use to
subscribe/unsubscribe to events.


5.5

Resource Manager

The resource manager will be provided as a java component (possibly an EJB).


FP6


504083

Deliverable 6.3





7

5.5.1

Interfaces

The mana
ger 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 implemen
t 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
.

Similar mapping problem is also addressed with the Locator inte
rface of the WSMO
API (section
6.1
), which maps logical IDs to physical addresses for WSMO elements.

5.5.2

Examples

The first example shows how
to use the
ResourceManager

interface.


package org.semanticweb.dip.examples.ResourceManage
r;

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




=resourceManag
erHome.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.


This is the interface declaration.

package org.semanticweb.dip.ResourceManager;


im
port java.net.URI;


public interface Mapper {


public void mapPhysicalURI(URI partialLogicalURI,URI physicalLocation) throws Exception;


public URI getPhysicalURI(URI fullLogicalURI) throws Exception;

}



FP6


504083

Deliverable 6.3





8

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.Ex
ception


*/


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 MapperI
mpl() {


}

}


5.6

Discovery

The discovery component will be available as a web service that exposes a single
interface


Discovery.

5.6.1

Interfaces

The discovery web service exposes two operations


DiscoverRankedServices

and
DiscoverRankedService
Urls
. The first t
akes 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"


FP6


504083

Deliverable 6.3





9


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


ta
rgetNamespace="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.semanticw
eb.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"


type="xsd2:ToBeSpecified"/>


</xsd:sequence>


</xsd:complexType>


<xsd:complexType name="Query">


<xsd:annotation>


<xsd:documentation>Query containin
g 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:se
quence>


</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"


FP6


504083

Deliverable 6.3





10


type="xsd2:Ra
nkedService"/>


</xsd:sequence>


</xsd:complexType>


<xsd:complexType name="ToBeSpecified">


<xsd:annotation>


<xsd:documentation>IMPORTANT: This type is used whenever further specifica
tion
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"


nam
e="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>


<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://schem
as.xmlsoap.org/wsdl/">OutMessage for the
DiscoverRankedServices operation</documentation>


<part element="xsd2:RankedServiceList" name="result"/>


</message>


<portType name="DiscoveryServicePortType">


<operation name="DiscoverRankedSe
rvices">


<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:DiscoverRankedServicesReques
t"/>


<output message="tns:DiscoverRankedServicesResponse"/>


</operation>


<operation name="DiscoverRankedServiceUrls">


<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Takes a query containing a
goal and r
eturns a ranked list of URLs to the discovered Web Service Descriptions </documentation>


<input message="tns:DiscoverRankedUrlsRequest"/>


<output message="tns:DiscoverRankedUrlsResponse"/>


</operation>


</portType>


<b
inding name="DiscoveryServiceBinding" type="tns:DiscoveryServicePortType">


<binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>


<operation name="DiscoverRankedServices">


<operation


soapAct
ion="capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServices"


style="document"/>


<input>


FP6


504083

Deliverable 6.3





11


<body use="literal"/>


</input>


<output>


<body use="literal"/>


</output>


</operation>


<operation name="DiscoverRankedServiceUrls">


<operation


soapAction="capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServiceUrls"


style="docum
ent"/>


<input>


<body use="literal"/>


</input>


<output>


<body use="literal"/>


</output>


</operation>


</binding>


<service name="DiscoveryService">


<port b
inding="tns:DiscoveryServiceBinding" name="DiscoveryServicePort">


<address location="http://localhost:8000/ccx/DiscoveryService"/>


</port>


</service>

</definitions>


5.7

Invocation

The invocation component is implemented as a java inter
face called
Invoker

that
exposes a single method called invoke:

invoke
(WebService webService, WSMLDocument document):

InvokerResult

5.8

Mediation (Data)

TODO: to summarize the interfaces specified in D5.2 and WSMX

5.8.1

Interfaces

5.8.2

Usage examples


FP6


504083

Deliverable 6.3





12


5.9

Semantic
Repositor
y

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 scope of 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
,
[7]
.
The ORDI implementation, on itself,
is

based on the
onto
logy representation
package of the WSMO API, presented in section
6.1
.

This comprehensive dependency
schema was implemented in order to make sure that
,

“by design”
,

the web
-
service
related tools (WSMO Studio) and the OMS are int
eroperable. Further, it assures that all
the tools based on these interfaces will be able to use various reasoning and repository
implementations, which implement them.



Figure 2.

Semantic Repository
-
related Interfaces

The interfaces f
or the Semantic Repository will be specified within an ORDI
imp
l
e
me
ntation. Its main features can be specified as follows:



To extend
the
org.wsmo.
I
O

sub
-
package
s

of the WSMO API

with further
interfaces, supporting behaviors and use cases necessary in ontol
ogy
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.P
arser

int
er
face for

(parsing of and serialization to)
different synta
xes and languages will be provided. The first candidates in this
direction are the RDF/XML syntax for RDFS and
OWL

and the XML WSML
Syntax.

WSMO Studio

SWS Integrated Development


Environment


WSMO4J

Reference Implementation


WSMO API

Interface Definitions


Ontology

Ontology
Management Suite





ORDI

Ontology Representation

& Data Integration



Repository

(
Sesame,

YARS)

Reasoner

(KAON2)

Other

Data
-

sources


FP6


504083

Deliverable 6.3





13



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 and KAON 2.
The later is the
reasoner developed within WP1.
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 w
ill meet 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 numbe
r 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 number of other WSMO
-
related
projects. T
his 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

one within the
WSMO API:


p
ublic interface

DataStore {


void save (Identifiable object);


Identifiable load (URIRef object
ID
);


boolean contains (URIRef object
ID
);

}


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

5.10

Web Service
Registry

5.10.1

Interfaces

The interfaces of the two web services that offer the public API of the DIP regi
s
try are
documented
respectively
in chapter
s 4.2 and 4.3
of
D4.2. We’ll provide here a brief
overview of them.

5.10.1.1

Publishing Interface

The o
peration
s

dipPublishService
,
dipPublishMediatorService
,
dipPublishOntology
,
and

dipPublishGoal

take
as parameters the business entity that owns the element

(strin
g)
, 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

FP6


504083

Deliverable 6.3





14

comment to D4.2
).
All of the four operations return the reg
istry 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.

5.10.1.2

Retrieval Interface

There are

four operations in this interface:
dipRetri
eveService
,
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
5.10.1.1

of D4.2.
The find query type
might

be missing
, AND is assumed in that case.


All the func
tions return a list of
t
he corresponding

type (
retrieveServiceResultType

for
service and mediator service,

retrieveOntologyResultType

for ontolo
gies, 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.

5.10.2

Usage examples

The java code
fragments

below provide

example
s

of using the DIP registry API

through
Apache WSIF.

The f
irst 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 WSDL definition as parameter.


WSIFServiceFactory factory=WSIFServiceFactory.newInstance();


WSIFService serv = factory.getService(def);


// Map the complex d
ipElementPropertiesAbstractType xsd type to a java class


// implementation


serv.mapType(


new QName("
urn:dip
-
org:publish_v1
", "dipElementPropertiesAbstractType"),


Class.forName(


"org.dip.ws.dipElementPropertiesA
bstractType"));


// 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.


WSIFO
peration op = port.createOperation("dipPublishOntology", "publishOntologyDescription",
"publishOntologyKey");


FP6


504083

Deliverable 6.3





15


// Create container for the input message


WSIFMessage input = op.createInputMessage();


// Create container for the output messag
e


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.dipElementPropertiesAbst
ractType 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/ti
me
-
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");


inpu
t.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.

package org.semanticweb.dip.examples.Re
gistry;

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"));


FP6


504083

Deliverable 6.3





16


serv.mapType(


new QName("urn:dip
-
org:retrieve_v1", "RetrieveOntologyResultType"),


Class.forName(


"org.dip.ws.RetrieveOntologyResult
Type"));



// 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 o
utput names as parameters.


WSIFOperation op = port.createOperation("dipRetrieveOntology", "QueryDipElements",
"retrieveOntologyResultList");


// Create container for the input message


WSIFMessage input = op.createInputMessage();


// C
reate 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.setPar
ts(inputParts);


// Execute operation


boolean success = op.executeRequestResponseOperation(input, output, fault);


if(!success) {


Iterator parts=fault.getParts();


while(parts.hasNext()) {


System.out.println(parts.n
ext());


}


} else {


org.dip.ws.retrieveOntologyResultListType ontologies =


(org.dip.ws.retrieveOntologyResultListType)output.getObjectPart("tns:retrieveOntologyResultListBody
");


org.dip.ws.RetrieveOntologyResu
ltType[] 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();}


}

}





FP6


504083

Deliverable 6.3





17

5.11

Choreography and Orchestration

The ORCA component is under development at the moment in WSMX
[5
]
. It will be
implemented as a java component
;

below we present the preliminary version of the API
of the component.

5.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);


}





FP6


504083

Deliverable 6.3





18

6

Additional common APIs

In addition to the component APIs there are also number

of other, in a sense lower
-
level, interfaces which are important for the interoperability across the tools and
components in DIP.

6.1

WSMO API

and Reference Implementation

The WSMO API is

a set of programming interfaces, which main function is to provide a
Ja
va binding for the WSMO semantic web services framework. The current version of
the WSMO API (RC2) is compliant with WSMO version 1.0
,

[2]
.

The strucutre of the
API

is depicted on
Figure 3
, where th
e dependency between the modules (Java
packages) goes from the bottom to the top.



Figure 3.

WSMO API and WSMO4J

Here follows brief enumeration and short description of the packages:



Common
:

the most general primitives, e.g.: identifie
rs, literals, variables, and
non
-
functional properties.



IO
: i
nput and output related
interfaces
, namely:



Parser
: taking care for parsing from or serialization to

a

particular
syntax;



Datastore
: defining the basic store and load interfaces
, see section
5.9
.



Locator
:
interfaces that allow physical locators to be mapped to logical
identifiers

in a flexible manner.

WSMO Studio

SWS Integrated Development


Environment






























Ontology
Management Suite





























WSMO API

Interface Definitions















WSMO4J

Reference Implementation












Common & IO

Ontology

Goal

Service

Mediator

In
-
memory
Structures

File Datastore

WSML Parser

ORDI

Ontology Representation

& Data Integration











Reasoner Wrappers

Im
port/Export Parsers

Repository Wrappers

Data Integration

Versioning

Mediation

Editing and Browsing


FP6


504083

Deliverable 6.3





19



Ontology
:
contains
ontology
-
specific interfaces (ontologies, concepts,

instances,
relations, axioms, logical expressions
, etc
.) This package represents the bridge to
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.ontol
ogy
.*
, in contrast to the other packages of
the WSMO API, which 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 pur
ely abstract set of interfaces. It means, that other programs may not
use it directly


they could only use a particular implementation of this interfaces.
W
SMO4J is a reference implementation of the WSMO API
, which allows its usage
without any further dev
elopment. 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
P
arser

interface (parsing and serialization) with respe
ct to
the WSML user
-
friendly syntax,
[10]
.



Implementation of the
Datastore

interface, providing persistency on top of
proprietary

binary
file storage
.



Implementation of the Locator interface.

The WSMO API and WSMO4J are open
-
sou
rce, 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,
[10]
.

6.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 in
customized web
-
service development environments. Those are
discussed

in a bit more
detail in D6.4,
[12]



here we only mention their existence.


The o
ntology 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 Eclipse
1

framework
,
version 3.0
.
The parti
cular 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 n
umber
of plug
-
ins, amongst which WSMO browser and editor.

As presented at
Figure 3
, WSMO Studio and the OMS will both use the WSMO API
(section
6.1
). The later together with Eclipse, provides sufficie
nt ground for
interoperability, even though, the two environments will be developed independently.




1

http://www.eclipse.org/


FP6


504083

Deliverable 6.3





20

7

C
ONCLUSION

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

d
ue

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 different, which could be accounted

to the early stage of the
development of the architecture.

While this was an expected situation, the project plan envisions, a update of the APIs to
be
presented in deliverable D6.9 “Revision of the components APIs”
.
It is the
understanding of the author
s, that the currently existing APIs provide sufficient level of
determinism to allow reasonably smooth software development in the middle phase of
the project.

FP6


504083

Deliverable 6.3





21

8

R
EFERENCES

TODO
: there reference fo
rmatting has to be unified


[1]

D. Roman, U. Keller, H. Lausen (e
ds.):
Web Service Modeling Ontology
-

Standard
(WSMO
-

Standard)
, 2004, version 0.2
.

http://www.wsmo.org/2004/d2/v02/

[2]

D. Roman, U. Keller, H. Lausen (eds.):
Web Service Modeling Ontology (WSMO)
,
2004, versio
n 1.0.
http://www.wsmo.org/2004/d2/v1.0/

[3]

Chris Preist and Dumitru Roman (eds.). D12v0.1. Web Service Modeling Ontology

-

Full (WSMO
-

Full), WSMO Working Draft 24 June 2004. http://www.wsmo.
org/2004/d2/v0
3/.

[4]

Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, and Katia Sycara. Semantic
Matching of Web Services Capabilities. In Proceedings of the 1st International
Semantic Web Conference (ISWC2002), 2002.

[5]

Michal Zaremba, Matthew Moran, Emilia Cimpian, Adri
an Mocan, Eyal Oren
,
Matthew Moran

(eds.):

WSMX Implementation

(
WSMO Working Draft
)
, 2004
, version
0.1
;
http://www.wsmo.org/2004/d13/d13.5/v0.1/

[6]

E. Oren
:
WSMX Execution Semantics

(
WSMO Working Draft
)
, 2004, version 0.1;
http://www.wsmo.org/2004/d13/d13.2/v0.1/

[7]

Atanas Kiryakov, Damyan Ognyanoff, Vesselin Kirov
. (2004)

An Ontology
Representation and Data Integration (ORDI) Framework. Deliverable

D2.2 of the
DIP

project.


[8]

Manfred Hauswirth, Roman Schmidt, Michael Altenhofen, Christian Drumm, Chris
Bussler, Matthew Moran, Michal Zaremba, Laurentiu Vasiliu, Joachim Quantz,
Laurent Henocque, Armin H
aller, Brahmananda Sakpota, Edward Kilgariff, Simeon
Petkov, David Aiken, Eyal Oren, Manuel Ohlendorf, Adrian Mocan.
DIP Architecture
.
Deliverable D6.2 of the
DIP

project.


[9]

Atanas Kiryakov, Christian Drum
m, Lina Al
-
Jadir, and et.al.
D5.2: Mediation

Module
Specification: Business Data
-
Level Mediation
. DIP deliverable. Dec. 2004

[10]

Marin Dimitrov, Damyan Ognyanov. (2004).
wsmo4j Programmer’s Guide
.
http://wsmo4j.sourceforge.net/doc/wsmo4j
-
prog
-
guide.pdf

[11]

J. de Bruijn, H. Lausen, and D. Fensel. The WSML Family of Representation
Languages, v0.2. DERI, Nov 2004.
http://www.wsmo.o
rg/2004/d16/d16.1/v0.2/20041126/
.

[12]

Vesselin Kirov, Atanas Kiryakov.
D6.4: Description of the external DIP APIs to be
used by the case studies
. (O
riginal

name:
Description of the mediation function
interface to be used by the case studies
) DIP deliverable.
Dec. 2004