Unify the description of web services and rdf data sources towards uniform data integration
1 / 24

Unify the Description of Web Services and RDF Data Sources towards Uniform Data Integration - PowerPoint PPT Presentation

  • Uploaded on

Unify the Description of Web Services and RDF Data Sources towards Uniform Data Integration. Wenfeng Zhao ( [email protected] ), Xiangwu Meng, Junliang Chen and Chuanchang Liu State Key Lab of Networking and Switching Technology,

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Unify the Description of Web Services and RDF Data Sources towards Uniform Data Integration' - beau

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Unify the description of web services and rdf data sources towards uniform data integration

Unify the Description of Web Services andRDF Data Sources towardsUniform Data Integration

Wenfeng Zhao ([email protected]),

Xiangwu Meng, Junliang Chen and Chuanchang Liu

State Key Lab of Networking and Switching Technology,

Beijing University of Posts and Telecommunications (BUPT)


  • Purpose and Background

  • Proposed Approach

  • Implementation


  • Purpose and Background

  • Proposed Approach

  • Implementation

Requirements for integration
Requirements for integration

  • The theme of SOA: Integration

    • Data Integration

    • Process Integration

  • Web Service V.S. Data Integration

    • Usually, WS is seen as the underlying interoperation facilities of DI systems as well as others.

    • In fact, some WS themselves are used just to provide data, especially dynamic data such as weather prediction and merchandise quotation to users.

  • So what if …

    • this kind of WS* is integrated into the DI system as a data-source such as database?

Data Queries

* The “Web Service (WS)s” in the following all refer to this kind, i.e. information-providing Web Service.

Traditional di technologies
Traditional DI technologies

  • Data Warehouse- copy (and transform) data in background; answer queries immediately.

    //ETL: Extract, Transform, and Load

  • “Federal system”- commit queries to data sources at runtime, given the local schema or global one is designed as a view over the other one (i.e. LAV or GAV).

We will follow this style.

Current ws technologies aren t adequate
Current WS technologies aren’t adequate

To describe the data schema, i.e. the semantic of the WS,

  • WSDL / BPEL / WS-CDL don’t work.

  • Semantic Web Service technologies are also inadequate!

    • OWL-S / WSMO / SAWSDL, considering Input/Output as concepts,aretoo coarse-grained, at least in context of data query.

How the service that provides book information given its topic is specified should be annotated?



topic: string;


title: string;

author: string;

pub_year: gYear;


like this ?



topic Book


title ?

author Person



or like this ?



topic Book



author Book



Given a typical Description Logic Class


topic: string;

title: string;

author: Person[ ];

pub_year: gYear;

isbn: ISBN;


Both inaccurate!

Neither do current semantic web tech
Neither do current Semantic Web tech.

  • RDFis the well-accepted Semantic Web data format standard.

  • SPARQL is the most-promising query language of RDF.

    • By considering it as a view, SPARQL is nearly capable of expressing the semantic of an information-providing Web Service.

A data query/view (in SQL)

SELECT title, author, publisher, pub_year

FROM book

WHERE topic= ‘Semantic Web’

and pub_year>2005 and topic…

  • But, like SQL, SPARQL can’t describe the meaning of Input of Web Services!

    • In the previous example WS, the input “topic” isn’t bound in advance, but required to be bound to a certain value while invocation.

    • How do SPARQL/SQL describe this type of “view”?


  • Purpose and Background

  • Proposed Approach

  • Implementation

Proposed approach uniform query


Proposed Approach – Uniform Query

  • (from WS viewpoint) Annotate Input/Output at the property level.

    • 1. Introduce some local individual of certain classes, which are connected by Object-Properties;

    • 2. Annotate each I/O leaf element of each message part with a Datatype-Property of an individual.

On the previous example:



topic  bk.topic


title  bk.title

author  ath.hasName

pub_year bk.publishYear



A Uniform Query



<ConcepthasURI="http://examples.org/travel#Book" />

<ConcepthasURI="http://examples.org/travel#Person" />



<Individualname="_:bk" typeIndex="0" />

<Individualname="_:ath" typeIndex="1" />



<Linkfrom="0" label="http://examples.org/travel#author" to="1" />



-<Selector indvIndex="0" property="http://examples.org/travel#publishYear">


<LowBound isInclusive="false">1900</LowBound>





<FieldindvIndex="0" property="http://examples.org/travel#amazonRank" />

<FieldindvIndex="0" property="http://examples.org/travel#publishYear" />

<FieldindvIndex="0" property="http://examples.org/travel#title" />

<FieldindvIndex="1" property="http://examples.org/travel#hasName" />



<FieldindvIndex="0" property="http://examples.org/travel#hasTopic" />



Grounding to WS – e.g. Amazon ECS

<ServiceStubAnnotation stubName="com.amazon.webservices.AWSECommerceService._2005_10_13.AWSECommerceServicePortType">

-<Operation name="itemSearch">

-<Binding uniformQueryID="2">











<ValueGivenpath="body/request[0]/searchIndex" value="Books" />

<ValueGivenpath="body/request[0]/responseGroup[0]" value="Medium" />

<ValueGivenpath="body/subscriptionId" value="1CXXQY……" />





partial annotation! (as SAWSDL)

Uniform query cont
Uniform Query (cont.)

  • From SW viewpoint, what we have done in Uniform Query is augmenting SPARQL with the concept “access pattern limitation [Hal01]” for a view to describe the correspondent of WS “Input”.

    • i.e. which variables/fields/properties, if any, must be bound when to query on a view.

  • So, SPARQL query and WS have a unified form.

    • With proper matching process between Uniform Queries, a WS can now be chosen to answer the SPARQL-like query.

    • Although there is no “Inputs” in the query, they can be derived from the “SelectionConditions” - the fields that are limited to a single value.

Matching criteria
Matching Criteria

The matching criteria of a Web Service type data source WS against a data query Q is that there exists an injective mapping from individuals of Q.Qps to those of WS.Qps under which that:

1) Q.Qps is entailed by WS.Qps (which means as directed graphs Q.Qps is sub-graph of WS.Qps);

2) The value spaces of Q.Sel and WS.Sel have a non-empty intersection.

3) Q.O should be (partially) entailed by WS.O, and

4) WS.I should be completely entailed by Q.I.

The result of the invocation of matched services might need to be filtered before returned to the user according to the difference of DS.Sel and Q.Sel.

Uniform query sparql query


Uniform Query  SPARQL query

  • The transformation is straightforward.

For example, a data query, in UQ, similar with and capable of being answered by previous WS is transformed into SPARQL as:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?o0 ?o1 ?o2 ?o3

WHERE { ?v0 rdf:type <http://examples.org/travel#Book> .

?v1 rdf:type <http://examples.org/travel#Person> .

?v0 <http://examples.org/travel#author> ?v1 .

OPTIONAL { ?v0 <http://examples.org/travel#amazonRank> ?o0 }

OPTIONAL { ?v0 <http://examples.org/travel#publishYear> ?o1 }

OPTIONAL { ?v0 <http://examples.org/travel#title> ?o2 }

OPTIONAL { ?v1 <http://examples.org/travel#hasName> ?o3 }

?v0 <http://examples.org/travel#hasTopic> ?l1 .

FILTER ( ?l1="Semantic Web" && ?o1 > "2005" )



  • Purpose and Background

  • Proposed Approach

  • Implementation

Proof of concept usdis uniform semantic data integration system
Proof-of-concept: USDIS*(Uniform Semantic Data Integration System)

Uniform Query

* Source codes is available at http://usdis.googlecode.com

Mechanism of dynamic ws invocation
Mechanism of Dynamic WS invocation

1) A set of <namePath, value> pair for Input, and

2) A set of <namePath> for Output.

Based on Java reflection mechanism.


  • In current version of USDIS, the expressivity of Uniform Query issimpler than SPARQL, especially in the selection condition.

    • The major limit is that the selection condition only supports thetree-like one, i.e. the attributes values could only be limited respectively rather than interactively.

    • This simplification make the GUI of query formulating easy to design and use.

Query result integration realized

Data from multiple data sources are converged!

Data from multiple data sources are aggregated!

Query Result – Integration Realized!


  • [Hal01] Halevy, A.Y.; Answering queries using views: A survey. VLDB Journal. 10(4) , 2001, pp.270-294


Thanks! 

USDIS source-code: http://usdis.googlecode.com

Wenfeng ZHAO (赵文峰)

PhD Candidate

[email protected]