telecom and informatics inf5120 modellbasert systemutvikling f13: model driven semantic...

Telecom and Informatics

INF5120Modellbasert Systemutvikling

F13: Model Driven Semantic interoperability – with Semantic web, Ontologies and Semantic SOA

Forelesning 28.04.2008

Arne-Jørgen Berre


Agenda

Lecture plan and pensum INF5120 Model Driven Interoperability (ref. F11) Semantic Web Ontologies and RDF, OWL Semantic Web services and SOA Semantic Annotation and reconciliation Semantic SOA


Lectures 1: 21/1: Introduction to MBSU, MDA, OO and Service/SOA modeling (AJB) 2: 28/1: Business Process Modeling (CIM) - with BPMN (AJB) 3: 4/2: Metamodeling and UML profiles, MDA technologies (EMF/GMF) – BPMN example (BRE) 4: 11/2: Language Engineering and DSL – SOA Example (BRE) 5: 18/2: Model transformations with ATL and QVT – and JEE (GO) 6: 25/2: SOA Architectures and UPMS (PIM) (AJB) 7: 3/3: Method Engineering and Service Modeling/SEMET (BRE) 8: 10/3: Code generation with MOFScript and other technologies (GO)

EASTER

9 :31/3:: Service Design and Patterns (AJB) 10: 7/4: PIM and Web Services technology (PSM) with WSDL/XML/BPEL (PSM) (BRE) 11: 14/4: Web services and Model Driven Interoperability (BRE) 12: 21/4: Architecture work at Telenor and Agent technologies (JOEA, Ismar) 13: 28/4: Model Driven Semantic interoperability–with Ontologies, Semantic web and SOA (AJB) 14: 5/5: Course summary, Course Handbooks/Material and updated Buyer/Seller Example (AJB) 15: 26/5 Preparation for exam, Course summary – QA and previous exams (AJB) Exam: June 2nd, 2008… AJB – Arne J. Berre, BRE – Brian Elvesæter, GO – Gøran Olsen


Model Driven Interoperability(ref. Lecture 11)


ATHENA Interoperability Reference Architecture

Enterprise/Business

Processes

Services

Information/Data

Cross-OrganisationalBusiness Processes

Collaborative EnterpriseModelling

Flexible Execution and Composition of Services

InformationInteroperability

Mo

del-D

rive

n In

tero

pera

bili

ty

Sem

an

tics

and

On

tolo

gie

s

Enterprise/Business

Processes

Services

Information/Data

Provided Required


Run-time

SemAnnot

Set#2

Internet SemRec

Rules#2

Local

Software &

Data

SwApp#1

Local

Software &

Data

SwApp#2Sem

AnnotSet#1

SemRec

Rules#1

ReferenceOntology

Architecture for semantic annotation and reconciliation

Reconciliation

Design-time


Semantic Web


Semantics

Semantics – ancient Greek for meaning σημαίνω – I signal, sign, show

Semantics has become a buzzword or even a fuzzword Example from a book about Eclipse:

“We’ll use the same mechanisms to navigate semantic errors (…) that we use to navigate compile errors.”

(failing tests) – semantic error is less precise than “failing tests” a fuzzword in this case

Oxford English Dictionary: 2. a. Relating to signification or meaning. (as adjective)


Semantics and Definitions

Standard way to communicate meaning is by definition

definition: “Verbal description of a concept, permitting its differentiation from other concepts within a system of concepts.”

– International Standard ISO 1087, Terminology – Vocabulary, 1990

The Semantic Web is about formalizing your definitions

“the Semantic Web, as envisioned by Tim Berners-Lee and many others since, is a logical extension of the current Web that enables explicit [machine-processable] representations of term meanings [concepts]”

– Frankel, David; Hayes, Pat; Kendall, Elisa; McGuinness, Deborah: MDA Journal July 2004


Formality Spectrum: formal

SAPtermSAPterm WordNetWordNet

"An ontology is an explicit and formal specification (based on logic) of a shared

conceptualization"

"An ontology is an explicit and formal specification (based on logic) of a shared

conceptualization"

Ontology, e.g, OWL ontologyOntology, e.g, OWL ontology

InformalInformal FormalFormal

Every tomato is red. for all x ( tomato (x) implies red (x) )

Every tomato is red. for all x ( tomato (x) implies red (x) )

Ontology


Concept, Object, Designation (term), and Definition

Definition

Designations (terms)

Object

Handy (DE)cellular phone, cell phone (US) (two variants)

mobile (UK)

A one-piece, hand-held phone that

includes battery powerand may be used

without any peripheralpower or antenna.

(Nokia)

Concept

term is verbal designation

term is verbal designation


More on the meaning triangle

morning star

morning star

evening star

evening star

An example from Gottlob Frege (1848-1925):

different termsdifferent concepts and definitions

same object, the planet Venus

An example from Gottlob Frege (1848-1925):

different termsdifferent concepts and definitions

same object, the planet Venus


The general vision

URI, HTML, HTTP

WWW

Serious Problems in information:

• finding • extracting

• representing• interpreting

• and maintaining

RDF, RDF(S), OWLSemantic Web

Bringing the web to its full

potential: data and semantic

interoperability


What is the Semantic Web?

The Semantic Web is a major research initiative of the World WideWeb Consortium (W3C) to create a metadata-rich Web of resources

that can describe themselves not only by how they should bedisplayed (HTML) or syntactically (XML), but also by the meaning of

the metadata.

From W3C Semantic Web Activity

The Semantic Web is an extension of the current web in whichinformation is given well-defined meaning, better enabling computers

and people to work in cooperation.

Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2001

Telecom and Informatics 16

Evolution of the semantic web


The Tree of Knowledge Technologies (Extended fromTop Quadrant)

SAWSDL

EXPRESSISO 15926

CC

WSMOOWL-SWSDL-S


Internet Evolution


Ontologies andOntology languages

(RDF, OWL)


RDF: Resource Description Framework

RDF is the simplest of the semantic languages. At the simplest level, the Resource Description Framework is an XML-based

language to describe resources.

Basic Idea #1: RFD uses triplesRDF is based on a subject-verb-object statement structure.RDF subjects are called resources (classes).Verbs (predicates) are called properties.Objects (values) may be simple literals or other resources.

• Basic Idea #2: Everything is a resource that is named with a URIRDF nouns, verbs, and objects are all labeled with URIsA URI is just a name for a resource. It may be a URL, but not necessarily.A URI can name anything that can be described.

Web pages, telephone numbers, concepts, creators of web pages, organizations that the creator works for….


Resource Description Framework (RDF)

A language for making simple statements about things (resources) Statements: Subject Predicate Object (triples)

Item1 isOrderFor Product1 Item1 is-a Item Product1 hasName “Lawnmower”

LineItem database table:LineItem database table:

subjectsubjectpredicatepredicate

objectobject


RDF and URIrefs

Things are identified by Uniform Resource Identifiers (URI, URIref) Avoids naming clashes

http://www.co.uk/vocabulary#Item1 (v:)

http://www.w3.org/1999/02/22-rdf-syntax-ns#type (rdf:)

Same example using namespace prefixes v:Item1 v:isOrderFor v:Product1 v:Item1 rdf:type v:Item v:Product1 v:hasName “Lawnmower”

Subject and Predicate are always resources Objects can be either resources or literals (see 3rd triple)


RDF data model

RDF statements can be expressed using XML syntax But, the RDF data model is a graph of nodes and directed arcs

Subjects and objects are nodes Predicates (also called Properties) are directed arcs from the

subject to the object. properties relate individuals to individuals (or values)

v:Item1v:Item1

v:Itemv:Item

11

rdf:typerdf:type

v:hasOrderQuantityv:hasOrderQuantity


RDF Schema compared to XML

Has a formal model-theoretic semantics

By contrast, there is no formal semantics for XML documents like po.xml po.xsd can be turned into

an ontology and po.xml into an instance of it

But, there is no standard algorithm to perform that transformation

no single interpretation

• <?xml version="1.0"?> <purchaseOrder orderDate="1999-10-20">

<shipTo country="US"> <name>Alice Smith</name>

<street>123 Maple Street</street>… </shipTo>

<billTo country="US"> <name>Robert Smith</name> …

</billTo> <comment>Hurry, my lawn is going

wild!</comment> <items>

<item partNum="872-AA"> <productName>Lawnmower

</productName> <quantity>1</quantity>

<USPrice>148.95</USPrice> <comment>Confirm this is electric

</comment> </item>

<item partNum="926-AA">… </items>

</purchaseOrder>


RDF:PurchaseOrder<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:po="http://example.com/purchase-order-ns" xmlns:addr="http://example.com/address-ns" xmlns:prod="http://example.com/product-ns"> <po:PurchaseOrder> <po:orderNumber>123456</po:orderNumber> <po:raisedBy> <po:Customer> <po:name>Wild Widgets Inc.</po:name> <po:customerNumber>1447389</po:customerNumber> </po:Customer> </po:raisedBy> <po:customerRef>XS31444</po:customerRef> <po:shipTo> <addr:StreetAddress> <addr:number>1421</addr:number> <addr:street>Plane Avenue</addr:street> <addr:town>1421</addr:town> </addr:StreetAddress> </po:shipTo> <po:lineItem> <po:Item> <prod:code>TYW-65523-GB</prod:code> <prod:color>TYW-65523-GB</prod:color> <po:quantity>15</po:quantity> </po:Item> </po:lineItem> </po:PurchaseOrder></rdf:RDF>


Ontology Web Language (OWL)

A more expressive ontology language Concepts (classes) can be described or defined

described – necessary conditions given defined – necessary and sufficient conditions

given Builds on RDF and can be expressed in several ways:

RDF XML-based syntax abstract syntax graphic UML-like

Has three sub-languages: OWL Full OWL Description Logic (DL) – maps to a DL, a

subset of predicate logic OWL lite – for simple taxonomies (class

hierarchies)


Logical languages for the Semantic Web

OWL

Web Ontology Language (sometimes called Ontology Web Languagea) language developed by the W3C's Web Ontology Working Group and intended to be the successor of DAML+OIL.OWL is the most expressive knowledge representation for the Semantic Web so far.

OWL has three levels of language: OWL Lite, OWL DL (for description logic), and OWL Full. These three levels are in increasing order of expressivity.



RDF/RDFS

The first language (RDF) expresses instance-level semantic relations phrased in terms of a triple: <subject, verb, object>, i.e., <object1, relation1, object2>. The second (RDFS) expresses class-level relations describing acceptable instance-level relations.

RDF/RDFS is considerably less expressive than OWL and DAML+OIL


Henri Parot

<owl:Property rdf:ID=“head”> <rdf:subPropertyOf

rdfs:resource=“member” /></owl:Property>

<owl:Class rdf:ID=“Terrorist”> <owl:sameClassAs> <owl:Restriction> <owl:onProperty

rdf:resource=“member” /> <owl:someValuesFrom

rdf:resource=“TerroristOrg” />

</owl:Restriction> </owl:sameClassAs>

</owl:Class>

ETA TerrorOrg

Terrorist

type

head

type

The head of an organization is also a member of it

A member of a terror organization is a terrorist

Therefore, the head of a terror organization is a terrorist


An example of the reasoning possibilities of the logical languages


RDFXMLLiteral

RDFSDatatype

RDFSLiteral

lexicalForm : String

TypedLiteral

datatypeURI : String

RDFSClass

0..*

+RDFSsubClassOf

0..*

PlainLiteral

language : String

RDFSResource

namespace : StringlocalName : Stringuri : String

0..*+RDFtype 0..*

0..*

+RDFScomment

0..*

0..*

+RDFSlabel

0..*

Metamodel for RDFS Classes


Metamodel for OWL Classes

OWLRestriction

RDFSClass(from RDFS)

OWLClass

complete : Booleandeprecated : Boolean

0..*

+OWLdisjointWith

0..*0..*

+OWLequivalentClass

0..*

Individual

EnumeratedClass

1..*+OWLoneOf 1..*

IntersectionClass UnionClass

OWLClass

2..*+OWLintersectionOf 2..*

2..*

+OWLunionOf

2..*

ComplementClass

1

+OWLcomplementOf

1


Metamodel for OWL Restrictions

RDFProperty(from RDFS)

OWLRestriction

1

+OWLonProperty

1

RDFSResource(from RDFS)

HasValueRestriction

1+OWLhasValue 1

AllValuesFromRestriction

RDFSClass(from RDFS)

1

+OWLal lValuesFrom

1

SomeValuesFromRestriction

1

+OWLsomeValuesFrom

1

CardinalityRestriction MaxCardinal ityRestriction

RDFSLiteral(from RDFS)

1

+OWMcardinal ity

1

1+OWLmaxCardinali ty 1

MinCardinali tyRestriction

1

+OWLminCardinality

1


Metamodel for OWL Properties

RDFProperty(from RDFS)

OWLObjectProperty

deprecated : Booleanfunctional : BooleaninverseFunctional : Booleansymmetric : Booleantransitive : Boolean

0..1

+OWLinverseOf

0..1

0..*

+OWLequivalentProperty

0..*

OWLDatatypeProperty

deprecated : Booleanfunctional : Boolean

0..*

+OWLequivalentProperty

0..*


IndividualOWLAllDifferent

2..*

+OWLdistinctMembers

2..*

RDFSResource(from RDFS)

RDFSLiteral(from RDFS)

DatatypeSlot

property : OWLDatatypeProperty

1..*

+content

1..*

Individual

0..*

+OWLsameAs

0..*

0..*

+OWLdifferentFrom

0..*

0..*

+datatypeSlot

0..*

ObjectSlot

property : OWLObjectProperty0..*

+objectSlot

0..*1..*

+content

1..*

Metamodel for OWL Individuals


OWL PurchaseOrder

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" <owl:Class rdf:ID="PurchaseOrderLine"> <rdfs:subClassOf> <owl:Class rdf:ID="PricedLine"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string> Inherits from Line and contains information related to delivery. </rdfs:comment> </owl:Class> <owl:ObjectProperty rdf:ID="changesLineValue"> <rdfs:range rdf:resource="#Amount"/> <rdfs:domain rdf:resource="#PricedLine"/> </owl:ObjectProperty> </rdf:RDF>


OWL versus UML

In OWL and not in UML Explanation

Thing, global properties, autonomous individual

In OWL, instances as well as some relations (in owl, relations are called properties), can exist without being attached to certain class. This is due to the fact that OWL is based on sets while UML is based on types. Instances and relations in OWL can be a subset of the universal class Thing or binary relation between two Things.

Class-specific cardinality redefinition

As OWL properties can be declared independent of classes, they can have different cardinality definitions when applied to different classes.

allValuesFrom, some ValuesFrom

“In OWL, property can have its range restricted when applied to particular class, either that the range is limited to a class (subclass of range if declared) (allValuesFrom) or that range must intersect a class (someValuesFrom).” [28]

SymmetricProperty, TransitiveProperty

OWL allows properties to be declared symmetric or transitive. In both cases the domain and range must be type compatible.

Classes as instances In UML or MOF defined languages, there is a strict separation of metalevels so that population of M1 classes is distinct from the population of M2 classes. In OWL full, one class can be an instance of another class, a characteristic inherited form RDF. In OWL DL, this usage is restricted.


UML Ontology profile


Semantic Web Servicesand SOA


Service Web


Semantic web service technologies

OWL-S (was DAML-S, US)

WSMO (Europe, DERI, STI, OASIS)

WSDL-S (basis for SAWSDL)

SAWSDL (W3C standard)

40

Telecom and Informatics41

OWL-S Ontology

OWL-S is an OWL ontology to describe Web services OWL-S leverages on OWL to

Support capability based discovery of Web services Support automatic composition of Web Services Support automatic invocation of Web services

"Complete do not compete" OWL-S does not aim to replace the Web services standards

rather OWL-S attempts to provide a semantic layer OWL-S relies on WSDL for Web service invocation (see Grounding) OWL-s Expands UDDI for Web service discovery (OWL-S/UDDI

mapping)

Telecom and Informatics42

OWL-S Upper Ontology

• Mapping to WSDL• communication protocol (RPC, HTTP, …)

• marshalling/serialization• transformation to and from XSD to OWL

• Control flow of the service•Black/Grey/Glass Box view

• Protocol Specification• Abstract Messages

•Capability specification•General features of the Service

• Quality of Service• Classification in Service

taxonomies


The Web Service Modeling Ontology (WSMO)


WSMO – Web Service Modeling Ontology

WSMO working group includes the WSML working group, which aims at developing a language called Web Service Modeling Language (WSML) that formalizes the Web Service Modeling Ontology (WSMO).

WSMO: an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Taking the Web Service Modeling Framework (WSMF) as a starting point, we refine and extend this framework, and develop an ontology and a description language.

WSML: aims developing a language called Web Service Modeling Language (WSML) that formalizes the Web Service Modeling Ontology (WSMO). Hereby, we have a two fold mission:a) developing a proper formalization language for semantic web services and b) providing a rule-based language for the semantic web


WSMF

WSMF [consists of four different main elements for describing semantic Web Services:

(1) ontologies that provide the terminology used by other elements,

(2) goals that define the problems that should be solved by Web Services,

(3) Web Services descriptions that define various aspects of a Web Service, and

(4) mediators which bypass interpretability problems.


WSMO Web Service Description Model


WSMO Working Groups

Conceptual Model & Axiomatization for SWS

Formal Language for WSMO

Ontology & Rule Language for the Semantic Web

Execution Environment for WSMO

www.wsmo.org

SEE TC

STI2 CMS WG

WSMO

WSML WSMX


Lifecycle

Discovery

find candidate WS to solve a Goal Selection & Ranking

select best candidate / determine a priority list Composition

combine several WS to solve a Goal Behavioral Compatibility

ensure that interaction can take place Mediation

resolve & handle possibly occurring heterogeneities Execution

automatically invoke & consume WS to solve a Goal


Semantically-Enabled Service-oriented Architecture

Semantic Execution Environment (Machine A)

StakeholdersLayer

System Administrator

Developer Tools(ontology management,

monitoring, ...)

Applications(user tools, access portals, ...)

Network(internet, intranet, extranet)

Service Requesters Layer

DomainExpert

Problem Formulation Layer

Software Engineer

Domain Ontologies

Discovery Adaptation

CompositionOrchestration Mediation Grounding

Fault Handling Monitoring

Back-end System Z

BusinessService S3

BusinessService S4SEE

(Machine D)

Middleware Layer

SEE(Machine C)

Back-end System X

BusinessService S1

User 1 User 2

Exe

cutio

n M

an

age

me

nt

Sec

uri

ty

Reasoning CommunicationFormal Languages Storage

Service Providers Layer

vertical broker

base

Shared Message Space

SEE(Machine B)


SAWSDL - Semantic Annotations for WSDL and XML Schema

W3C Standard August, 2007

This specification defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how such semantic annotation is accomplished using references to semantic models, e.g. ontologies

3 constructs: modelReference, liftingSchemaMapping, loweringSchemaMapping


A Web Service Composition Scenario with Ontology Reasoning


Semantic Annotations for WSDL and XML Schema

W3C Working Draft 10 April 2007

This specification defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how such semantic annotation is accomplished using references to semantic models, e.g. ontologies. SAWSDL does not specify a language for representing the semantic models. Instead it provides mechanisms by which concepts from the semantic models, typically defined outside the WSDL document, can be referenced from within WSDL and XML Schema components using annotations.


Semantic Annotation


• Building an annotation expression:

1. Using an existing concept of RO

or2. Creating a new concept by

composing elements of RO

• Linking the annotation expression to the resource

Semantic Annotation Process overview

Annotated resource ( RDF)

Link

Build an annotation expression

Annotation expression

{ x|9y(Invoice(x)

^hasTotal(x,y)^Total(y)) }

Reference Ontology

Totla

VAT NetPrice

Invoice

ItemProce

RFQ ACME

……………..……………..……………..


COIN Semantic toolset - streamline for semantic interoperability

ARGOS

ReconciliationRules

Generator

ReconcRules

ARES

Enterpr B

ReconciliationEngine

MSGA

(SOAP)

MSGB

(SOAP)

Enterpr A

Sem. Reconciliation

Athos ReferenceOntology

OntologyManagement

System

A*

SemanticAnnotation

tool

AnnotationRepository

Design Time Run Time

BPModels Docs WS

ASSERT

Sem. Search

Themis

ReconciliationRules

Generator

ModelsRepository

SemanticSearchEngine


ARGOS: a Transformation Rules Building toolA graphical environment supporting a user in defining

transformation rules guided by

Document model Annotations Reference Ontology A set of Rule Templates

using an abstract but expressive syntax

An intuitive interface supports the user in parametrising transformation templates (Rule Templates)Instantiated Rules are automatically transformed by ARGOS into

executable code (Jena rules) for the reconciliation engine (ARES)


ARGOS: Rule Templates

The most common kinds of interoperability clashes occurring within documents have been analysed

Clashes can be solved applying Transformations consisting of one ore more Rule Templates

Main ARGOS Rule Templates: Merge Split Map MapValue Convert Sum Mult


Ontology-based reconciliation

Local Schema Local Schema

Enterprise A Enterprise B

SemanticAnnotation

SemanticAnnotation

ReconciliationRules

CustomizedMRE

CustomizedMRE

ReconciliationRules

Local Data Local Data

Design phase

Run-time phase

Interch.Repres.

Reference

Ontology

FWD transf BWD transf

BWD transf FWD transf

SW App SW App

Semantic Mediation and Reconciliation

Platform

Semantic Mediation and Reconciliation

Platform


Example of Mismatch

Structuring

Purchase Order

• Order_Number

• Order_Date

• Buyer_Info– Name

– Address• Street_Name• Street_Num• City_Post_Code• Country

– Telephone

• Products_Info– Product_Code

– Description

– Quantity

– Price (unitary)

• Currency (Dollar, Euro, Pound)

• Charge

• RequestedDeliveryDate

Sale Order

• Date• Organization_Name• Contact_Person• Location

– Street_Address– City– LoCode– Country

• Phone_Number– Area_Code– Number– Ext

• Client_Order_Number• Order_Lines

– Product_Code– Description– Quantity– Price (total per line)

• Currency (USD, Euro, Yen)• Total

EnterprA (Buyer) EnterprB (Supplier)


Ontology-based Reconciliation Approach

Address

Street Snum CountryZip_Code

Location

Street_Address

Reference Ontology

City

Street_Name

Street_Number

City-Post_Code

Country

LoCode

Country

City


Local Schema (LS) Reference Ontology (RO)

Purchase Order (PO)…Address … City-Post_Code: literal

Address [ … City : literal Zip_Code: literal ]

Structuring Clash

Example of actual reconciliation

LS.PO.Address.City-Post_Code =:

RO. Address.City AND RO.Address.Zip_Code

Semantic Annotation

unpack(LS.PO.Address.City-Post_Code, “-”)

(RO.Address.City, RO. Address.Zip_Code)Reconciliation

Rule

{“Rome - 00185”} {“Rome”, “00185”}Run-time Reconciliation


From Semantic Annotation to Transformation Rules

order.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson. hasPart _FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart _Surname

>:

AIDIMA order

RO

orderorder

orderheaderorder

header

productsinfo

productsinfo

supplierinfo

supplierinfo

buyerinfo

buyerinfo

orginfoorginfo

contactpersoncontactperson namename

orgNameorgName

addressdetails

addressdetails

productrecord

productrecord

descriptiondescription

productCodeproductCode

quantityquantity

……

……

……

buyerOrderNumberbuyerOrderNumber

……

……

orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


PurchaseOrderPurchaseOrder

OrderLineOrderLine

IDID IssueDateIssueDate

BuyerBuyer

SupplierSupplier

ContactPerson

ContactPerson

SurnameSurnameFirstNameFirstName

ProductProduct

LinePriceLinePriceQuantityQuantity

BOD BOD

AA AA

BODAA

BA

CABA

BA

AA

AA

DescriptionDescriptionAA

NameNameAA

YearYearAA

MonthMonthAA


BuyerBuyer

ContactPerson

ContactPerson



BuyerBuyer

ContactPerson

ContactPerson


Split

SSAX

SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

INTOPurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname

ForwardTransf Rule


An example of Transformation Rule in the Jena2 syntax

NameSplitting: [(?x0 rdf:type ai:order) (?x0 ai:has_orderHeader ?x1) (?x1 rdf:type ai:orderHeader) (?x1 ai:has_buyerInfo ?x2) (?x2 rdf:type ai:buyerInfo) (?x2 ai:has_organizationInfo ?x3) (?x3 rdf:type ai:organizationInfo) (?x3 ai:has_contactPerson ?x4) (?x4 rdf:type ai:contactPerson)(?x4 ai:has_name ?x5)]

[(?x0 rdf:type ro:PurchaseOrder_BOD) (?x0 ro:relTo_Buyer ?x2) (?x2 rdf:type ro:Buyer_BA)(?x2 ro:relTo_ContactPerson ?x4) (?x4 rdf:type ro:ContactPerson_BA)Split(?x4, “ ”, ?y1, ?y2, 'http://www.w3.org/2001/XMLSchema#string')(?x4 ro:hasPart_FirstName ?y1) (?x4 ro:hasPart_Surname ?y2)]




ForwardTransf Rule

Rule in the Jena2 syntax


From Semantic Annotation to Transformation Rules

order.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson. hasPart _FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart _Surname

>:

AIDIMA order

RO

orderorder

orderheaderorder

header

productsinfo

productsinfo

supplierinfo

supplierinfo

buyerinfo

buyerinfo

orginfoorginfo


orgNameorgName

addressdetails

addressdetails

productrecord

productrecord

descriptiondescription

productCodeproductCode

quantityquantity

……

……

……

buyerOrderNumberbuyerOrderNumber

……

……

orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo



OrderLineOrderLine

IDID IssueDateIssueDate

BuyerBuyer

SupplierSupplier

ContactPerson

ContactPerson


ProductProduct

LinePriceLinePriceQuantityQuantity

BOD BOD

AA AA

BODAA

BA

CABA

BA

AA

AA

DescriptionDescriptionAA

NameNameAA

YearYearAA

MonthMonthAA


BuyerBuyer

ContactPerson

ContactPerson



BuyerBuyer

ContactPerson

ContactPerson


Split

SSAX




ForwardTransf Rule


An example of Transformation Rule in the Jena2 syntax

NameSplitting: [(?x0 rdf:type ai:order) (?x0 ai:has_orderHeader ?x1) (?x1 rdf:type ai:orderHeader) (?x1 ai:has_buyerInfo ?x2) (?x2 rdf:type ai:buyerInfo) (?x2 ai:has_organizationInfo ?x3) (?x3 rdf:type ai:organizationInfo) (?x3 ai:has_contactPerson ?x4) (?x4 rdf:type ai:contactPerson)(?x4 ai:has_name ?x5)]

[(?x0 rdf:type ro:PurchaseOrder_BOD) (?x0 ro:relTo_Buyer ?x2) (?x2 rdf:type ro:Buyer_BA)(?x2 ro:relTo_ContactPerson ?x4) (?x4 rdf:type ro:ContactPerson_BA)Split(?x4, “ ”, ?y1, ?y2, 'http://www.w3.org/2001/XMLSchema#string')(?x4 ro:hasPart_FirstName ?y1) (?x4 ro:hasPart_Surname ?y2)]




ForwardTransf Rule

Rule in the Jena2 syntax


Semantic SOA


Semantic SOA: Discovery / Selection

Semantic SOA Vision Application Composition based

on existing building blocks (services) Business Process Flexibility

Requirements Discovery of appropriate candidate services Selection of the best matching service

An Approach for Solution Semantic annotation of service capabilities and requestor’ goals

Unambiguous, machine-interpretable formalizations Business context & data ontologies Advantages

(Semi-)automatic discovery of candidate services (Semi-)automatic integration of new services Self-adaptable business processes through automatic selection of services

Service YGoal

Potential candidate

Service X Goal

No match

Discovery

Service Y

Service Z

Potential candidatesConcrete

Task

Ranking/Composition

Selection


Semantic SOA: Mediation

Semantic SOA Vision Application Composition

based on existing building blocks

Requirements Integration of different

services Mapping between different

message formats

An Approach for Solution Semantic annotation of message

formats using ontologies Unambiguous, machine-interpretable formalizations Business data ontologies

Advantages Semi-automatic creation of necessary transformations Reduced development effort Simplified integration of legacy systems/applications

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration OntologyPerson

First nameSurnameAddress

AddressStreetCityPostal Code

hasType

ClientClient codeCase worker…

Is a

…<CLT>

<CLTCD>1234</CLTCD><NAME>Joe Doe</NAME> <CITY>WDF</CITY><POCODE>12345<POCODE>

</CLT>…

…<Customer>

<FirstName>Joe</FirstName><SurName>Doe</SurName> <Address>

<City>WDF</City></Address>

</Customer>…

1234

JoeDoe

WDF

12345

Sourcemessage

Targetmessage

AutomaticData Mediation

Creating ontology instance from source message

Creating target message instance from ontology instance

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration OntologyPerson

First nameSurnameAddress

PersonFirst nameSurnameAddress



hasType



Is a

…<CLT>


</CLT>…

…<Customer>



</Customer>…

1234

JoeDoe

WDF

12345

Sourcemessage

Targetmessage





Semantic SOA: Composition Semantic SOA Vision

Business ProcessFlexibility

Requirements Defining placeholders

for process steps Matching of business contexts Describing data compatibility

An Approach for Solution Goals as placeholders Service semantics described by ontologies

Unambiguous, machine-interpretable formalizations Business context & data ontologies (static aspects) Business collaboration ontology (behavioral semantics)

Sales Order Processing

OrderOrder

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration Ontology

Invoice Processing

InvoiceInvoice

Web Service

Capability I

Capability

Web Service

Capability II

Purchase Order

Processing II

PurchasePurchaseOrder IIOrder II

Purchase Order

Processing I

PurchasePurchaseOrder IOrder I

Goal

Process Matching & Process Matching & MediationMediation

Purchase Order Processing Goal

Advantages Reasoning allows for automatic composition of processes Automatic integration of new services Self-adjusting business by using placeholders


Discovery/Selection, Mediation, and Composition benefit from using Semantics

‘SOA isn‘t enough’Semantics – prerequisite for Semantic SOA

Semantic SOA

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration Ontology



hasType


Is a

…<CLT>


</CLT>…

…<Customer>



</Customer>…

1234

JoeDoe

WDF

12345

Sourcemessage

Targetmessage




Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration Ontology





hasType



Is a

…<CLT>


</CLT>…

…<Customer>



</Customer>…

1234

JoeDoe

WDF

12345

Sourcemessage

Targetmessage





Conclusion and outlook Support for semantics with ontologies and mediation is available

now Short term benefit can be gained in the area of services for

semantic interoperability – through the use of ontologies, and use of mappings and transformations for information and service interoperability

i.e. – start here from an industrial perspective, establish ontologies, use these directly or mediate through semantic annotation.

Semantic Web Services and Service-oriented Semantic Architectures (SESA) is a promising future technology

Longer term benefits can be expected related to matching goals with services for process and service composition and process interoperability

72

telecom and informatics inf5120 modellbasert systemutvikling f13: model driven semantic...

Documents

literal address city

rule templatesusing

rule templatesthe

transformation rules

literal zip

reconciliation platformtelecom

literal telecom

ha haspart