Schema and Ontology Matching with COMA++ David Aumueller, Hong-Hai Do, Sabine Massmann, Erhard Rahm University of Leipzig, http://dbs.uni-leipzig.de Leipzig, November,29th 2005
Introduction Schema matching: ● ●
Input: 2 schemas e.g., DB Schemas, XML message formats Output: Identification of correspondences between elements Schema 1 Cust C# FirstName LastName Street Zip
Schema 2 Customer CustID CustName PostalCode Street Phone
Application domains: ● ● ● ●
November, 29th 2005
Data integration E-business Data warehousing Semantic query processing
2
Introduction (2) Development of many techniques and prototypes to semiautomatically solve the match problem
[from: A survey of approaches to automatic schema matching, E.Rahm, P.A. Bernstein, VLDB Journal 10:4 2001] November, 29th 2005
3
COMA++ Generic, customizable schema matching tool Generic data model to uniformly support schemas and ontologies written in different languages (W3C XSD, XDR, OWL, Relational) Repository for uniform management of ● ● ●
Schemas, ontologies Match results Auxiliary information
Flexible combination of matchers to construct new matchers and match strategies Optimized implementation of matchers for fast execution times New approaches for ontology, reuse-, context-, and fragment-based matching Platform for comparative evaluation of matchers and match strategies High-level operators for manipulating match results, e.g. compose, merge, and compare mappings GUI (Java Swing)
November, 29th 2005
4
Architecture of COMA++ Graphical User Interface Execution Engine Matcher Iteration
External Schemas, Ontologies
Component Identification
Schema Pool Schema Manipulation
Matcher Execution
Similarity Combination
Match Customizer
Mapping Pool
Matcher Definitions
Match Strategies
1
n
n
Object Id n Source Id Accession Text Number
1
November, 29th 2005
1
1
n
n
OBJECT_ REL
SOURCE_ REL Source Rel Id Source1 Id Source2 Id Type
Mapping Manipulation
OBJECT
SOURCE Source Id Name Structure Content 1
Exported Mappings
1
Object Rel Id n Source Rel Id Object1 Id Object2 Id Evidence
Repository
5
Match processing Parsing
Preprocessing Directed graphs S1
Match Iteration Constituents {s11, s12, ...} {s21, s22, ...}
S2
XSD, OWL, XDR, SQL,...
Resolve, Reduce, Simplify
Parser Library
Preprocessing Library
November, 29th 2005
Nodes, ... Paths, ... Resolution Library
Matcher execution Matcher 1 Matcher 2 Matcher 3 Name, Children, Leaves, NamePath, … Matcher Library
Similarity cube
Combining match results s11↔s21 s12↔s22 s13↔s23
Aggregation, Direction, Selection, CombinedSim Combination Library
Mapping Pool
Mapping
Diff, Intersect, Union, MatchCompose, Eval, ... Manipulation Library
6
Match-Strategies AllContext:
Match between all unique contexts, i.e. paths
FilteredContext:
Two-phase matching ● ●
S1
Node matching Context (path) matching only for most similar node pairs
Ship
Cust
sCity
cCity Schema Decomposition
Ship Cust sCity
cCity
Ship Cust Ship
Cust
sCity
cCity
Nodes
Paths
Fragment-based (automatic, step-by-step):
Decomposition of large schemas and matching at fragment level ● ●
Identify similar fragments of specified type Match between similar fragments
Fragment contexts
PO Bill
Ship Addr
Fragment graph/ Local contexts City November, 29th 2005
7
Match-Strategies (2) Reuse (automatic, manual):
S1
Determination of mapping paths from existing match results to solve a new match tasks
S2
S6
S3 S5
m1
S1 firstName lastName
0.9
0.7
S3 FName LName
m2
S2
0.7
m3 = MatchCompose (m1, m2)
Name
S4
m3
S1 firstName lastName
0.7
S2
0.8 Name 0.7
Taxonomy:
Match input schemas to a selected taxonomy and combine match results Model 1
Taxonomy
Order Order sim(m2k,tk) Contact InvoiceTo InvoiceTo DeliverTo tsim(ti,tk) DeliverTo Product sim(m1i,ti) Product
November, 29th 2005
Model 2 Order Contact Product
8
Demo
November, 29th 2005
9
Schema Evolution* Frequent need to change schemas ● ● ●
Improve original design / remove design errors New application requirements New data source for global schemas …
High degree of manual work to deal with database schema evolution ● ● ● ●
Schema redesign Data migration Evolving dependent mappings Adapting dependent applications
* Model Management Solution Patterns for Schema Evolution Erhard Rahm, Phil Bernstein, Sergey Melnik November, 29th 2005
10
Model Management MM operators very promising for schema evolution ● ● ● ●
Automated processing of entire schemas and mappings Compact solution patterns Reuse of previous mappings Low degree of manual interaction
Previously proposed MM scripts for schema evolution (Vision2000, ER2000, CIDR2003, SIGMOD2003, Diss2004, ICDE2004 tutorial, SIGMOD2005 …) ● ● ● ● ●
November, 29th 2005
Based on different sets of operators Different assumptions for mappings and mapping language Early scripts heavily use Match – not fully automatic Later scripts heavily use Compose / Invert of mappings limitations for composability / invertibility Scripts often address only subset of problems (e.g. only insert or delete propagation) 11
Mapping Considered Evolution Problems Mapping generation for changed schema ● ●
Direct mapping generation (Map) Incremental mapping generation
Mapping evolution due to schema change ●
S’ S’
SS mapS-S’
Source evolution (SE) - Simple source evolution (SE1) - Change propagation (SE2) Delete propagation (S-DP) Insert propagation (S-IP)
●
Target evolution (TE) - Simple target evolution (TE1) - Reverse engineering (TE2) Delete propagation (T-DP) Insert propagation (T-IP)
Schema reintegration November, 29th 2005
12
Simple Source Evolution 1. Direct Match solution mapS’-T = Match (S’, T) Not fully automic Reuse of existing mappings (?)
2. Compose solution (Example 1) 1. mapS’_S = embed (S’, S) // mapS-S’ may not be invertible 2. mapS′ -T = mapS’_S ◦ mapS-T // reuse of mapS-T TT
TT mapS-T
SS
mapS’-T
mapS-T S’ S’
S’ S’
SS a) No target change
mapS-S’
mapS-S’
☺
November, 29th 2005
Simple and fully automatic Result may be incomplete due to added schema elements 13
Simple Source Evolution (2) 3.
Combined solution (Example 2) 1. mapS’_S = embed (S’, S) 2. mapS′ -T1 = mapS’_S ◦ mapS-T // maximally reuse ex. mapping to T 3. = Diff (S’, mapS’-T1) // S’ subset not yet mapped to T 4. mapS1-T = Match (S1, T) 5. mapS′ -T2 = mapS’-S1 ◦ mapS1-T 6. mapS’-T = mapS’-T1 ⊕ mapS′ -T2 // confluence TT mapS1-T
mapS-T mapS’-T1
SS mapS-S’ ☺
November, 29th 2005
S1 S1
S’ S’ Diff: mapS’-S1
Added schema elements are as well considered ( Not fully automic) 14
Change Propagation = SE2 (S, T, mapS-T, S’, mapS-S’) Consider invertibility of mappings mapS-T may not be total, e.g. T may have components unrelated to S (must be retained) User should decide about which changes (e.g. deletes) should really propagate / cascade Assumption: schemas are represented in same (super) metamodel Delete propagation, insert propagation TT
TT
T’ T’ mapT-T’
mapS-T mapS-T SS
S’ S’
b) With target change
mapS’-T’ SS
S’ S’
mapS-S’ mapS-S’
November, 29th 2005
15
COMA++ Simple Source/Target Evolution possible Change Propagation not Currently assuming 1:1 relations m1
S1 firstName lastName
S3 FName
m2
S2 FName LName
m3 = MatchCompose (m1, m2)
S1
m3
S2
firstName
FName
lastName
LName
No support of key/keyref at the moment
November, 29th 2005
16
References Aumüller, D., Do, H.H., Massmann, S., Rahm, E: Schema and Ontology Matching with COMA++. Proc. SIGMOD 2005 (Software Demonstration), Baltimore, June 2005 Rahm, E., Do H.H., Maßmann, S.: Matching Large XML Schemas. Sigmod Record 33(4), December 2004. Do, H.H., Melnik, S., Rahm, E.: Comparison of Schema Matching Evaluations. Proc. GI-Workshop "Web and Databases", Erfurt, Oct. 2002 Do, H.H., Rahm, E.: COMA - A system for flexible combination of schema matching approaches. Proc. 28th Intl. Conference on Very Large Databases (VLDB), Hongkong, Aug. 2002 Rahm, E., Bernstein, P.A.: A Survey of Approaches to Automatic Schema Matching. VLDB Journal, Vol. 10, No. 4, Dec. 2001
November, 29th 2005
17
Thanks.
November, 29th 2005
18
E-Commerce-Projekt InnoRegio Musicon Valley: Untersuchungen zur Entwicklung von kundenorientierten E-Commerce-Lösungen in regionaler Kooperation für KMU und Handwerk im Musikinstrumentenbau Prof. Dr. Erhard Rahm Institut für Informatik, Universität Leipzig http://dbs.uni-leipzig.de
Motivation
E-Commerce ist für den Vertrieb von Musikinstrumenten von zunehmender Bedeutung Kunden erwarten weitgehende Unterstützung bei Information und Kauf Von einigen Herstellern bereits in unterschiedlichen Entwicklungsstufen eingeleitet Aber: oft fehlen noch Wissen und Unterstützung für professionelle Nutzung Enge Abstimmung mit den betroffenen Unternehmen und Organisationseinheiten (Fertigung, Vertrieb, etc.) notwendig
Projektskizze
System zur Unterstützung von E-Commerce-Lösungen für regionale Musikinstrumentenbauer Plattform soll Modellcharakter für weitere Unternehmen der Region haben Berücksichtigung verschiedener Ausbaustufen Anforderungsanalyse Berücksichtigung der Besonderheiten der Branche Verwaltung/Pflege durch geschulte Mitarbeiter sowie durch externe Partner möglich
Projektpartner
Universität Leipzig:
Recherche
und Aufarbeitung vorhandener Lösungen für E-Commerce im Musikinstrumentenbau
Anforderungsanalyse
Konzeptionelle Entwicklung der Plattform
Evaluierung / Verfeinerung
Musicon Valley e.V.:
Bindeglied
zwischen beteiligten Unternehmen und Entwicklern
Marketingstrategien
Projektpartner(2)
Informationsagentur VIA GmbH
Internetagenturen der Region Modellhafte Ausarbeitung und Erprobung der Plattform mit ausgewählten Partnerunternehmen
Externe Unterstützung für Unternehmen
Schulung der Mitarbeiter der Unternehmen
Unternehmen des Musikinstrumentenbaus
Involvierung in allen Projektphasen (Anforderungsanalyse, Entwicklung, Evaluierung)
Gefördert durch BMBF
Unternehmen des Musikinstrumentenbaus
Bandonion- und Concertinafabrik GmbH
Weltweit bekannt Æ einer der wenigen Hersteller von Bandonions B2C (Verkauf an Endkunden) Verkauf quasi nur über Mail, selten Fax Geringe Anzahl Instrumente, dafür jedoch mehrere Optionen möglich
Mastri
Mastri & Friends
Präsentation mehrere Instrumentenbauer Geigen, Cellos, Bögen
Website Æ Imagegewinn, Kunden interessieren/informieren Verkauf fast nur über Fax B2B (also Verkauf eher an Händler, weniger Endkunden) Aufbau der Preislisten beibehalten als Orientierung für Händler Æunterschiedlich für jeden Unternehmer
Aspekte der Branche
Kunden aus der ganzen Welt Æ Unterstützung mehrerer Sprachen Æ Beachtung rechtlicher Aspekte (AGBs,..) und Kosten (Versandkosten, Zoll/Steuern) Aufbauf und Pflegen von Kundenkontakten viel über Messe Æ Ankündigung von Messen/Events Bestellung noch über Telefon, Fax & Mail; Informationsaustausch zusätzlich über Flyer/Listen Æ Plattform soll informieren & Kommunikation „übernehmen“ Geschichte, Herkunft & Fertigung wichtig Æ Darstellung auf Plattform Qualität (keine Massenware), Bau von Instrumenten fast nur nach Bedarf/Bestellung Æ Konfiguration von Wunschinstrumenten Æ Personalisierung der Preise Zielgruppe nur teilweise bewandert im Umgang mit Internet Æ Einfach & übersichtlich halten Æ Viel „Schnickschnack“ von anderen E-Shops überflüssig (z.B Bestseller, Bewertungen durch Kunden) Bau (von Instrumenten) dauert meist mehrere Wochen Æ Status der Fertigung zusätzlich zum Bestellstatus Da Kunden wahrscheinlich zusätzliche Kommunikationsmittel nutzen Æ Admin muss z.B. Bestellung für Kunden aufgeben können, dessen Profildaten ändern, etc. Bezahlung zur Zeit meist nur über Vorkasse Æ Unterstützen weiterer Möglichkeiten (Kredikarte, ePayment …)
Aktueller Stand
Anforderungsanalyse Auswertung
vorhandener Seiten von Musikinstrumentenbauern und Online-Shops Auswertung vorhandener E-Commerce-Systeme rechtlicher Aspekte
Erstellen bzw. Zusammenstellen benötigter Infos durch die Instrumentenbauer (Fotos, Texte, Informationen) Erstellung zweier Plattformen
Ursprünglich nur eine geplant benötigt, da beide Unternehmen eigene (unterschiedliche) Ansprüche Verwendung von Open Source Software (xtCommerce, MySQL) Schnittstelle zu DV-Systemen
Workshops
Voraussichtlich Sommer 2006 Für die Musikinstrumentenbauer der Region Vogtland Präsentation
der
Plattformen
Auswertung des Aufwandes & Nutzen
Vor- und Nachteile
Verwendung der Modellplattformen (ganz oder Module)
