Semantics Enriched Service Environments

Wednesday, August 12, 2009

Homer wants to drive from Athens, GA to NYC.


and would like to have his favorite burger all through the way.


He drives to the apple store, gets his iPhone and excitedly downloads the aroundme
application that allows him to ﬁnd restaurants near him.


and then realizes that he has to do too much before he can ﬁnd a mcdonalds!!


he sits to create his own application coz he has heard that even 9 year olds can create apps.


but its not that easy for an average user!

How do we help Homer ﬁnd his Big Mac?


Four


we break down this task into four steps


ﬁrst is to ﬁnd the right services that give Homer all the information?


When one service responds, we need to send it to the next service. however, its not easy. so
let us resolve the dispute here and make them
talk


once we have made them talk, we will make sure that they are all integrated.


all is good, but when Homer is using the app, things can go wrong! how can we identify
something when it happens?

SEMANTICS ENRICHED
SERVICES ENVIRONMENT
Karthik Gomadam,
Services Research Lab,
kno.e.sis center.
http://gomadam.org
http://slideshare.net/namelessnerd
http://twitter.com/namelessnerd


In this talk, I will discuss my research in addressing these four questions. We have attempted
to address signiﬁcant parts of each problem
and have used semantic Web techniques for the same. First, I will very brieﬂy talk about
Service Oriented Architecture. SOA is at the heart of my work.


One can have many kinds of services: Data services that expose and share data; Software as a
service: Where a software functionality can be remotely utilized; platform as a service: Where
one can provide a suite of tools and expose an integration platform as a service. SOA allows
us to create software that is easy to conﬁgure, ﬂexible and agile.


Along with SOA, my work also employs semantic Web techniques. The Semantic Web is an evolving development of the
World Wide Web in which the semantics of information and services on the web is defined, making it possible for the web to
understand and satisfy the requests of people and machines to use the web content. In this work, we largely employ RDF as
the framework for modeling metadata.


RDF expresses resources in the form of subject predicate object expressions, called triples. In
the above example, the resource me is the subject, fullName is the predicate and Eric Miller is
the object. Similar for other nodes and edges. RDF represents a labeled, directed
multigraphs. For those of you unfamiliar, this example is from the wikipedia page of RDF and
will be familiar when you look it up.

Semantic Web Services

= Semantic Web + Web Services


The other area of research that this work borrows from and has contributed towards is
Semantic Web Services. Simply, put SWS as it is called is adding semantics to Web services.
There are many approaches to do this.

Semantic Web /
Semantic Models


This bringing together of SW and WS can be done in two ways. The ﬁrst one is where, Services
are added into semantic Web.

Semantic Web /
Services
Semantic Models


This bringing together of SW and WS can be done in two ways. The ﬁrst one is where, Services
are added into semantic Web.

Service aspects represented in
semantic models


In doing so, we represent aspects of a service such as its inputs, outputs, operations using
semantic models.

OWL -S


Signiﬁcant in this is OWL-S. In OWL-S, there is a semantic model to capture the proﬁle of a
service read from picture. relies on description logic.

WSMO

Goals, Ontologies, Mediators, Web Services


• Goals - The client's objectives when consulting a Web Service.
• Ontologies - A formal Semantic description of the information used by all other components.
• Mediators - Connectors between componentes with mediation facilities. Provides interoperability between different ontologies.
• WebServices - Semantic description of Web Services. May include functional (Capability) and usage (Interface) descriptions. Relies
on F-Logic.

Services

Semantic Web /
Semantic Models


The second approach is one where we ground service descriptions in semantic metadata.
This is a bottom up approach and does not
require a signiﬁcant change in perception of a service.

METEOR-S


The METEOR-S project adopts this approach.

Execution Data
Event Identification, Not just model,
Adaptation Express your data

Non-
Functional Functional
Response time, What does the
Cost, QoS Metrics service offer?


We classify the semantics for services into four types.


And capture these within a service using modelrefernce, an extensibility attribute. WSDL
schema allows extensibility attributes to represent additional properties beyond WSDL
description. We deﬁne an extensibility attribute, called model reference that allows the
addition to semantic metadata to WSDL elements.

Resourceful Web


These services exposed various resources on the Web such as feeds, APIS

described in X/HTML


easy for humans to read and understand but hard for machines. The problems related to
description and interop still remain.

SA-REST*:

semantic microformat for resource markup.

*- Not an acronym


During standardization process of SAWSDL in 2005, we realized that there was an emerging
paradigm of services, one that did not necessarily have a WSDL for description.

inline semantic annotations that refer

to a rich semantic model


SA-REST is an approach to add rich semantic markup to web resource descriptions. It builds
on top of microformats, which have become an easy way to add semantic markups for
calendar entries, contact information etc. I am currently editing the W3C submission of SA-
REST, as a part of W3C incubation group for SWS. From these markups, one can extract RDF
representation of the resource that can be used in search, data integration (when resources
are used in a mashup). (Yahoo already has provision for using RDFa for extracting additional
semantic meta information while crawling).
Feedbooks allows you to browse using many facets such as theme, author, Let us look at an
example markup of a simple Web page.

site level


Everything in this site is related to basketball. capture this information at this high level.

iPhone app, unit
conversion

block level

iTunes store, song
pricing


element level


really deep markups.. i want to markup for each thumnail link info about that episode

site-domain-rel

markup the domain of an entire site

markup to the entry page of the site

applies to /*


http://dooduh.com

<body class= ‘dooduh-main site-domain-rel’ title= ‘dbpedia:web2.0’>


We look at the body element of the entry to page ESPN’s basketball site and markup that says
that the site content belongs to the domain described in this semantic model (in this case
dbpedia’s basketball)

domain-rel


when used without site, domain-rel simply denotes the domain of a block of content. it is a
block markup.
in a site, when domain-rel is used in an inner resource, the domain of the resource is what is
mentioned by this domain-rel

multiple domains


in our example, the article talks not just about iphone apps but also about unit
conversion(which is what the app does)

<p class=”domain-rel”
title=”dbpedia:iphone
dbpedia:unit_conversion”>


in this case, we enumerate the domains (no speciﬁc order)

sem-rel


not all links are created by us.. say we are blogrolling. there is no guarantee that the target
resource of a link is marked up too.
but being socially responsible, we want to throw some hints at what to expect off a link. also
allows enumeration

In summary


Real world applications
Technology Centric Data and Control flow Service types
and services

SOAP / WSDL
OWL-S - DL IOPE Very few evaluations
Haibo Zhao’s work on
WSMO - FLogic Either or scenarios available
RESTful composition

Technology Data flow: Mediatability
independent - use any Control flow: SOAP / WSDL and APIHut, FoxyREST,
upper level modeling Declarative RESTful Dooduh, AIR
language composition


We present a quick comparison of prior research and thesis. In the dissertation I have
discussed this in detail. I have compared thesis of
Dr. Paolucci, Dr. Mocan from WSMO, Dr. zhao from UGA (who worked on RESTful composition
with only control flow considerations).


two months ago in my prospectus,

Faceted API Search, Discovery and
Mediatability


I presented our approach to Faceted API search, SWS discovery and data mediation. I will
brieﬂy discuss these contributions today.

Key word based paradigms

Interface based techniques


the keyword based search paradigm is extremely successful in the context of Web search,
keywords are not sufficient to describe the desired functional and non-functional aspects of
services.

The other paradigm supported by UDDI is interface-based discovery. In this approach, certain
popular interfaces can be published in a registry and services conforming to them can be
classiﬁed as such. This approach has the limitation that the interface itself is treated as a
black box and there is no mechanism to compute relationships between the interfaces.

Our observation is that a number of services with similar functionality may have syntactically
different interfaces, but similar or even equivalent semantic signatures.


The SA-REST annotations of the APIs used apiHUT taxonomy, illustrated here as the semantic
model; the semantic model available in RDFS.

OUr search engine uses a hybrid of bayesian statistics, TF-IDF for text analysis and
classiﬁcation along with available semantic markups.

Serviut Rank


Serviut rank is our approach to ranking. It is very similar to the popular Page rank. Page rank
is computed using inlinks nad outlinks.
Serviut rank employs a similar strategy using the number of mashups that use a service as a
positive referral, the total number of
services that do a given task and total number of mashups. In addition to this, we also use
the popularity of teh application itself. This is given by Alexa.

Query Precision Recall
Query1 0.89 0.75
Query2 0.83 0.69
Query3 0.54 0.71
Query4 0.82 0.21
Query pWeb ApiHut Google
Table 1: Precision and Recall of ApiHut
Query1 0.48 0.89 0.20
Query2 0.61 0.83 0.13
Query3 0.25 0.54 0.23
Query4 0.70 0.82 0.37

Table 1: Precision : Apihut, PWeb and Google


SEMRE: SEMantic services
REGistry


Syntactic
interface
agreement
required!
Manufacturer 1 Manufacturer 1
Create and publish semantic Create and publish semantic
Manufacturer 1 Manufacturer 2 interface contract 1 in SAWSDL interface contract 2 in SAWSDL
Create and publish service Create and publish service annotated with concepts annotated with concepts
interface contract 1 in WSDL interface contract 2 in WSDL from the ontology from the ontology

Service Provider 1 Service Provider 2 Service Provider 1 Service Provider 2
private registry private registry private registry private registry

Publish service 1 that Publish service 2 that
adhere to the service adhere to the service Publish service 1 that
interface contracts of Publish service 1 that
interface contracts of adhere to the ontology
manufacturer 2 adhere to the ontology
manufacturer 1

Service Provider Service Provider


Builds upon what is called as contract ﬁrst. WSDL is the contract that binds a provider and a
requestor. Rather than having a keyword driven
contract, SEMRE adopts SAWSDL and enables a semantic contract. allows us to reason at the
meta level while computing matches.

1. semantic interface signature (Semantic Template)

2. identify fulfillment set: RE ,
S θ
RE and D
RE
3. all fulfilling interfaces:

4. Interface relation in the set defined above


parallel, each attribute fulfillment is computed independently. Map function computes this.
reduce aggregates.

Matching comparison
180

160 153

140
Number of Matches

120

100
87

80

60

42
40

20

0

Data Only Match Data and Operation Data and Operation and
Domain


Published 200 services of which 42 were relevant for a request. Our approach worked well.
Data only did worst and data and operation did
slightly better. We do note here that we tested on services that are completely annotated.
More annotation meant more processing and this test set served well for timing tests. Also
we note that all three approaches had the same beneﬁt of high quality annotation

Think Meta!!!
“Anything you can do, I can do Meta”
Charles Simonyi, Intention Software


This is our approach to data mediation. Charles Simonyi is the creator of M$ office, the
computer scientist who went to space.


Rather than mediate between individual schemas, one can write reusable mediation scripts
between concepts in the metamodel. Once individual schemas are annotated, one can create
Lifting schema mapping and lowering schema mapping.

Many services for the same task


Ease of mediation


Our approach is to calculate the ease of mediation

Mediatability


Given two data models (schemas) how easy can a user mediate between the two?

Top down - Mediation Similarity


Compute the similarity of the two schemas. This is structural, and semantic.

Bottom up - Mediatability



User evals; asked to mediate between Yahoo Web, Image search, live search, google search
and Flickr; System is conservative. Normal user: average user with some Web dev experience,
expert user : apache XML Schema committers , hardcore mashup developers.


In the next part of my talk, I will discuss our work on declarative based approach for
integration

Declarative


Our approach to composition is declarative. By this we mean, the input to the composition
can be richly described with additional
parameters such as semantic annotations, semantic templates and a smashmaker DSL.

Semantic Templates


Collection of template terms


Snapshot of
Rosettanet PIP Event
Ontology
has_input ISA ISA notifies_event
Input_Message has_output
Action_PIP has_notification Notification_PIP
Output_Message ISA
ISA
ISA ISA ISA
ISA has_output
CancelOrder_Output
PurchaseOrder_Input CancelOrder
RequestPurchaseOrder PIP3A4
PurchaseOrder_Output
PIP3A4

has_output

CancelOrder_Input
has_output
has_input

Semantic Template
ServiceLevelMetaData (SLM)
Category= NAICS:Electronics
Template
ProductCategory= DUNS:RAM
Location= Athens,GA
metadata
SemanticOperation Template (SOPT1)
Action= Rosetta:RequestPurchaseOrder Legend
Input= Rosetta:PurchaseOrder_Input Operation Modelreference
Output= Rosetta:PurchaseOrder_Output
OLP= {Encryption = RSA, ResponseTime< 5 Sec}
SemanticOperation Template (SOPT2)
Requirement for
Input Modelreference

Action= Rosetta:CancelOrder operation
OutputModelReference

Input= Rosetta:CancelOrder_Input
Output= Rosetta:CancelOrder_Output
OLP= {Encryption = RSA, ResponseTime< 5 Sec}


Semantic templates are often more formal and have many enterprise quality features such as
support for policy. So we will deviate a bit
from Homer Simpson and look at a game manufacturer. In this example, talk about the
template.

So what happens to Homer and his burger?


{
"smashup": {
"device": "iPhone",
"code": {
"title": "Address Finder",
"sketch": {
Get current
"service": {
"type": "component",
location
"resource":
"http://smashmaker.dooduh.com/operation/reversegeocode"
},
service": {
"type": "service-api",
"resource":
"http://smashmaker.dooduh.com/operation/returnAddress",
"endpoint": "http://dooduh.com/returnMickyDee.php",
"method": "GET",

"input-resource":"http://smashmaker.dooduh.com/datatype/address",
"input-param":"address"
},
"service": { Find McD’s
near location
"type": "i-smashlet",
"resource":
"http://smashmaker.dooduh.com/operation/ismashlet",
"source":"http://smashmaker.dooduh.com/datatype/address"
},
"service": {
"type": "o-smashlet",
"resource":
"http://smashmaker.dooduh.com/operation/osmashlet",

"target":"http://smashmaker.dooduh.com/datatype/location-info"
},
Add to map
"service":{
"type": "component",
"resource": "http://smashmaker.dooduh.com/operation/map"
}

}
}
}


this is a declarative speciﬁcation of a smart mashup in JSON. We chose JSON because, it is
easier to generate this from a Web interface.
The current platform does not have an UI as creating a UI like Yahoo Pipes would require a
considerable amount of effort, that we hope
to pursue once the middleware is stable. Going back to the example , explain the example.

Modeling an abstract Web service


Our approach to composition is generic and does not fundamentally differentiate between
SOAP and RESTful services. We ground
services to a common model, something we call an abstract Web service.

A collection of operations
Each operation is a collection of
1. Input
2. Output
3. Preconditions
4. Effects
5. Faults


Composition: Check and Add


Check


Precondition of current operation holds, along with the semantics of the available data entails
a valid input to the operation

Does the output of Restaurant service return location?


Add


Apply the transition function or the operation to the input and to the status ﬂags of the state
and transition to the next state.

Extract location (transition function) add to composition


plan is a DAG (Directed Acyclic
Graph) of operations


ie it is a set of operations that given a goal and an initial state, applies the check and add
operators until the goal is reached.

Graph plan


Many apporaches can be adopted. We adopt graph plan, since its sound and complete. That
means, if there is a valid plan, we will ﬁnd it.

What about DATA?


Conventional AI planning looks at Preconditions and effects. services have data

Semantic approach to check


AI planning does not mandate anything beyond regular string matching. we go one step
further and employ logic based semantic matching / graph based.

Loops


Unique to our approach is data based loop generation. If the data is an enumeration, our
planner generates a loop. For example in the
iPhone app, each address location is mapped.

Data Mediation as a service


smashlets


Smashlets are a unique category of service that do data mediation. Going by our user driven
approach, we allow users to share their mediation scripts using either SAWSDL or SA-REST
annotation in APIHut. The task of data mediation is then similar to that of service
discovery and check and add. user can specify a smashlet as an iSmashlet (input smashlet) or
(oSmashlet) output smashlet. The notion
of smashlets is something we veriﬁed very recently and is not in the dissertation. However,
mediation as a service is discussed.


A big thanks to Meena for laying this out so clearly. We intend to publish this as a guide for
Figure 7.3: Different Heterogeneities
people wanting to write smashlets. This will
give them a clue about what kind of mediation can they do, how easy it is to mediate.
106

events


In a distributed environment like SOA, with many components events are common place.

Event of direct consequence


We classify events into two types: events of direct consquence. resulting from an action by the
provider or the requester. such as
event raised when location information is made available in our application. The location info is
obtained asynchronously using a delegate protocol and when the info is available, the delegate
raises an event.

Event of indirect consequence


something that we did not intend or cause. such as a network outage.

what matters and what doesn’t?


the last part of my talk deals with how we can identify what events matters to our objectives
and what dont?

built over our declarative models

semantic template smashmaker DSL


extends semantic association computation


THE ρP AT H QUERY OPERATOR


Figure 8.1: Identifying Events from semantic Template
The enterprise space offers us a rich example. so we bid adieu to Homer’s burger here.
however we will bring him back when we walk through the algorithm. Here we have 2 models,
one a functional ontology that
captures the different operations, and their protocols; the second is a non-functional
ontology that captures various QoS metrics. We reuse
c associations between different entities. The semantic assoc
the popular OWL-QoS coalition ontology for non-functional and RosettaNet for functional.
The approach is to ﬁnd out what the goal is and ﬁnd the events modeled in the functional
ontology related to that goal. Grab the event and look at the non-functional ontology. That
will tell us what non-func properties are affected by this event. Check if any of those are in
path between the entities in the ontology. There can be more tha
our requirements.

Path is a collection of vertices and edges in a graph


to calculate this association, we extend the rho operator, proposed by Kemafor in 2003.

ρpath
Queries an ontology and returns
a set of vertices and edges between two
nodes AKA semantic association


bounds and constraints


however we need to get some bounds and constraints on rho

Large graphs - endless search - timeouts


bounds because in large graphs we can get into an endless search and that will leave running
instances with timeouts

really not all paths lead to Rome!!!


we are not interested in all paths that are within a bound. For example, we want the path to
contain atleast one edge that has a label
notiﬁes_event. otherwise that path tells us nothing about an event, and is not useful for our
purpose. similarly there can be many other constraints.

Extend rho to find all paths between
an entity and a class


as a first step, we extend rho operator to find paths between an entity and all entities
belonging to a class.

We deﬁne a set of classes and relationships
of interest


For example, we can deﬁne a set that has classes of operations, their inputs and the events
raised. Such as

{maptask, coordinate, location, location obtained}
{has input, has output, raises delegate}


Path satisﬁability: If every node returned is
in the set of classes and every relationship is
in the set of relationships.


{fetch location, gpsCoord, address, CLLocationDelegate}


In the context of iPhone, we have a fetch location operation which is of type maptask,
CLLocationDelegate the delegate that is raised
when the async response is obtained.

Bounded constrained rho is one where
all relationships statisfy the constraint and are bounded


{fetch location, gpsCoord, address, CLLocationDelegate}
if we add a bound of 4 to this satisfying constraint
then this is a bounded constrained path of bounds 4


Identifying events


EDC’s

get the semantic annotation on the operation


the semantic annotation on the operation must be in any of the paths. so that is added to the
constraint. Next is to add events that
are related to this association. we can ﬁx the bounds and get the events. the events are
related to an operation concept by a set of relationships that can be known apriori. we add
the relationships. events that belong to the bounded constrained path are events of interest.

EIC’s

get the concepts from the policy


EIC’s are obtained in a similar manner, but by using the non-functional requirements.

how relevant is an event?


not all events have the same relevance. relevance is deﬁned as a function of the path length.

shortest path over an event path


we calculate the relevance by factoring the shortest path we got and the path of an event.
This gives the relative importance of the event
over the most important event.

events can affect many metrics


an event can affect many metrics. hence we compute the cumulative relevance of an event.

ﬁltering


once this is done, we use normalization to identify events of relevance.

adjusting importance


once this is done, we use normalization to identify events of relevance.

ﬁxed relevance adjustment


where we observe the reaction of the underlying system to an event and evaluate it against it
calculated importance. if an event deemed non relevant causes a reaction every time, we add
a ﬁxed delta to its over all relevance. similarly we deduct delta for the other case.

variable/hybrid relevance adjustment


after the adjustment see how many events change status from relevant to non-relevant. if
many events change, we are way off base.
so adjust delta. keep checking this entropy and stop this adjustment if entropy is zero for a
certain time interval.

mulative relevance of the events in the non-relevant set after each feedback iteratio

d change in the value of the cumulative relevance coupled with the increased num

classified as non-relevant by the framework, being actually relevant, increases the ite

to stabilize the system.

.3: Studying the performance of hybrid and fixed Adjustment schemes with var
the total number of events.

126

8.4: Performance of hybrid and fixed adjustment schemes with variation in the perc
of relevant events


we compare how many iterations it takes for the system to stabilize in both the approaches.
as we can see the hybrid approach since it
he hybrid approach gives a better performance. However the variation to the cut-o
constantly adjusts almost maintains a constant convergence time and always converges
faster. the second experiment measures hte same
can have this impact on the accuracy of relevant events.
metrics, an time varying the percentage of the system. Our next set of experiments stu

cy of the system with respect to variations in the number of events and the percen

LUATION Augus
ents. The fourth experiment measures the variation in accuracy of both the

: Variation in the accuracy of feedback schemes with increase in the number

hen the total number of events is changed. This is illustrated in Figure 8.5.

isionexperiment measures how any irrelavant events we findin the total number of even
this of the hybrid approach with the increase with both approaches for every
relevant event. the flip side to the hybrid
apporach is that on an average it finds more irrelvant events intially, as it tries to first find the
d optimalthat of thevalue. approach. The adjustment made to the cutoff releva
than adjustment fixed

roach is responsible for this. This adjustment makes it possible for an event

vant by the feedback to manager, to be identified again as relevant by the fram

conclusions


Environment


Rather than a speciﬁc problem, this dissertation outlines what is possible with what is out
there today. we have created an environment
that facilitates various tasks involved in creating a service oriented ecosystem. we have
addressed the problems of discovery mediation
composition and execution in a service type agnostic manner.

Contributions to standards community


We have been actively involved in standardization and have contributed in terms of standards
(SAWSDL , SA-REST) as well as refernece
implentations. By grounding our research in these standards, we have also demonstrated the
usefulness and the values of these standards.
Our prototypes have always demonstrated comparable performance in terms of scalability
and better performance in terms of doing the job at hand.

marrying old school services with the
cool restless RESTful crowd


We are one of the ﬁrst to publish and implement a unifying search engine framework to
search both Web APIs as well as conventional services.

social approach


By having user annotated services, sharing nad discovery in the context of mashups we have
demonstrated the value of incorporatin g
social computing in services computing.

tooling


beyond reference implementations, we have released open source tooling that is used in the
community along with a bunch of
Web based easy to use systems; we will soon release RESTful APIs (need to migrate to cloud)
that will make it easier to use.

Dr. Amit Sheth, for letting me do what I want
for the most part of my research. This is a priceless
feature of this work environment.

Dr. Lakshmish Ramaswamy for guiding me through my
research including my ﬁrst paper at ICWS 07.

Dr. Kunal Verma for mentoring me and for continued
collaboration and friendship

Kaarthik Sivashanmugam for getting me started on Web
services


there was a technological freedom and allowed me to play with all sorts of areas.


I wish to really thank Topher, Meena, Cartic and Ajith for making sure I stand here today.
Ajith was and I hope will con

Badri Viswanathan Prof. Randy Pausch


Also thank two people who were instrumental in this progress who are not here with me. My
very good friend Badri who convinced me
to start this journey in 2002 and Dr. Randy Paush, from whom I learnt two valuable lessons.
Brick walls are there to keep those who dont want it badly out and you beat the reaper not by
living long and by living well and by inspiring people to live well.

and one more thing...


resourceful
many to many model eg: annotation
social contributions
APIHut and RESTful aspects goes towards incorporataion of
social web as part of the service Web framework
Used this for lightweight services, same thing can be
extended to WSDL / SAWSDL
Wiki based approaches.
and such .. last slide(s)


Here is Homer Simpson

Semantics Enriched Service Environments

Recommandé

Recommandé

Contenu connexe

Similaire à Semantics Enriched Service Environments

Similaire à Semantics Enriched Service Environments (20)

Dernier

Dernier (20)

Semantics Enriched Service Environments