Telecom and Informatics INF5120 Modellbasert Systemutvikling F13: Model Driven Semantic...
-
Upload
ashley-hart -
Category
Documents
-
view
232 -
download
0
Transcript of 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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
Model Driven Interoperability(ref. Lecture 11)
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
Semantic Web
Telecom and Informatics
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)
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics 17
The Tree of Knowledge Technologies (Extended fromTop Quadrant)
SAWSDL
EXPRESSISO 15926
CC
WSMOOWL-SWSDL-S
Telecom and Informatics 18
Internet Evolution
Telecom and Informatics
Ontologies andOntology languages
(RDF, OWL)
Telecom and Informatics
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….
Telecom and Informatics
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
Telecom and Informatics
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)
Telecom and Informatics
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
Telecom and Informatics
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>
Telecom and Informatics
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>
Telecom and Informatics
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)
Telecom and Informatics
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.
Telecom and Informatics
Logical languages for the Semantic Web
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
Telecom and Informatics
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
Logical languages for the Semantic Web
An example of the reasoning possibilities of the logical languages
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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..*
Telecom and Informatics
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
Telecom and Informatics
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>
Telecom and Informatics
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.
Telecom and Informatics
UML Ontology profile
Telecom and Informatics
Semantic Web Servicesand SOA
Telecom and Informatics 39
Service Web
Telecom and Informatics
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
Telecom and Informatics 43
The Web Service Modeling Ontology (WSMO)
Telecom and Informatics 44
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
Telecom and Informatics 45
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.
Telecom and Informatics 46
WSMO Web Service Description Model
Telecom and Informatics 47
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
Telecom and Informatics 49
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
Telecom and Informatics 50
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)
Telecom and Informatics 51
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
Telecom and Informatics 52
A Web Service Composition Scenario with Ontology Reasoning
Telecom and Informatics 53
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.
Telecom and Informatics
Semantic Annotation
Telecom and Informatics
• 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
……………..……………..……………..
Telecom and Informatics 56
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
Telecom and Informatics
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)
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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)
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
contactpersoncontactperson namename
orderorder
orderheaderorder
header buyerinfo
buyerinfo
orginfoorginfo
contactpersoncontactperson namename
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
PurchaseOrderPurchaseOrder
BuyerBuyer
ContactPerson
ContactPerson
SurnameSurnameFirstNameFirstName
PurchaseOrderPurchaseOrder
BuyerBuyer
ContactPerson
ContactPerson
SurnameSurnameFirstNameFirstName
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
Telecom and Informatics
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)]
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
Rule in the Jena2 syntax
Telecom and Informatics
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
contactpersoncontactperson namename
orderorder
orderheaderorder
header buyerinfo
buyerinfo
orginfoorginfo
contactpersoncontactperson namename
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
PurchaseOrderPurchaseOrder
BuyerBuyer
ContactPerson
ContactPerson
SurnameSurnameFirstNameFirstName
PurchaseOrderPurchaseOrder
BuyerBuyer
ContactPerson
ContactPerson
SurnameSurnameFirstNameFirstName
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
Telecom and Informatics
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)]
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
Rule in the Jena2 syntax
Telecom and Informatics
Semantic SOA
Telecom and Informatics 68
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
Telecom and Informatics 69
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
AddressStreetCityPostal Code
AddressStreetCityPostal Code
hasType
ClientClient codeCase worker…
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
Telecom and Informatics 70
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
Telecom and Informatics 71
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
PersonFirst 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 Ontology
PersonFirst nameSurnameAddress
PersonFirst nameSurnameAddress
AddressStreetCityPostal Code
AddressStreetCityPostal Code
hasType
ClientClient codeCase worker…
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
Telecom and Informatics
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