1. Contrasting typical SW and DB approaches to semantic integration
Arnon Rosenthal

2. Two versions of a common problem
Schema matching ≈ Align classes/properties in ontology
Two meta-models, similar core problem
Start with either:
Two domain models
Two schemas (for systems)
One domain model and one schema
Goal: Identify the relationships between
their concepts
their instance sets
same as, IS-A, “usable for” seem the main ones helpful to a “customer”
May need to transform to make things match

3. Decades have elapsed!
Database side: Survey of schema matching research (Batini et. al., 1986)
Target schema may be constructed from inputs
Envisioned end product is a SQL view
Focus is on “where can we find clues”
Sem-Web precursors: ISI, MCC – domain model (in logic) plus articulation axioms
Constraints are within the logic
Reasoning-based. Each project had its own formalism
Obvious question: Why no robust products yet?

4. Leaping ahead to my conclusions (SW competitor)
For enterprise systems today, lean toward DB and XML tools,
unless you really exploit ontologies’ greater expressive power (value taxonomies, IS-A)
Maturing sem-web environments will (by definition) import knowledge from big data integration products
Our customers can assimilate at most one “big thing” at a time.
Service oriented architectures have been anointed, and suck the oxygen from others.
Still room for Sem-Web in niches.

5. Correspondence topology
Direct approaches
Neutral form approaches (can be multiple)
Requests are mapped backwards
Use object correspondences,(Match, Derive attrib) create instance-set mapping (Map)
Domain model

6. Emerging work – not associated with systems
Multiple intermediaries
Which to use when creating? describing?
Domain model 1
Domain model 2
Domain model 3

7. Compare typical DB vs. AI approaches (1)
Formalisms to describe concepts & relationships DB (Schema) AI (Ontology)
Basic unit: relation or tree scheme
Record is a good chunk for storage or display
Sets are present, implicit
Describe a system or a physical message
Basic unit: atomic concept (object or property)
Small chunks  easy to relate & reuse
Describe a domain model
Robust for multiple uses
Small chunks are easier to reuse: (e.g. Castano et. al., TODS)
Storage and display convenience means somewhere in a system, you’ll have something record-oriented. So you need to sell that a second formalism is worth introducing.
In either approach, as you refine definitions, you subtype. That’s easier with ontology, somewhat clumsier in relational and XML systems.

8. Compare typical DB vs. AI approaches (2)
Formalisms to describe concepts & relationships DB (Schema) AI (Ontology)
Direct relationships and flows between systems
Instant gratification (funding is usually for an applic’n, not for integrat’n)
Differences in real data lead to improved definitions
Tools examine the data
$billion industry 
feature-rich, scalable tools
Relate via neutral defns
Reuse is easier
Will administrators understand “foreign” or abstract concept defns?
Small chunks are easier to reuse: Castano et. al., TODS.
In either approach, as you refine definitions, you subtype. That’s easier with ontology, somewhat clumsier in relational and XML systems

9. Compare typical AI vs. DB approaches (5)
DB AI
Homegrown logic
Even simple Datalogs won’t interoperate
extensible
Mappings are in popular query languages
Efficient: parallel, query optimizers
Deployable e.g., change management
OWL has both theory and tool communities
extensible
Execute by inference engine?
Not tuned to query processor strengths

10. Compare typical AI vs. DB approaches (3)
DB AI
Relationships among sets, via {informal or formal logic assrtns.} or query language
More powerful (data exchange logicians)
Terminology: TGD =  שڅ
View defns are big: hard to edit (and to reuse)
Relationships among concepts: “Usable_for”
Rel’ships use formalism very similar to ontologies
IS-A is “native”, i.e., part of the regular model
IS-A logically merges the ontologies
OWL is insufficient, rule languages overkill
Can use Similar to IS-A within ontology, but do not inherit attributes

11. Compare typical AI vs. DB approaches (4)
DB AI
Exchange semantics
examined from user viewpoint, precise
Hard to learn or communicate
Discards tuples unnecessarily?
Exchange semantics: Whatever my engine infers !!!
Is this tolerable? Why (not)?

12. How can they combine Formalism: Direct or via neutral model:
OWL ontologies
Need a standard construct for “can be used for” super-property ≈ tuple-generating dependencies
Direct or via neutral model:
Mix and match, share info and infer over both
Execution environment: DBMS
Parallel, query optimization, deployment
Already bilingual (SQL, XML), add RDF when it reaches critical mass ($Bs)

13. Why “Alignment” research is hard to transfer
Conspicuous lack of widely-used products, from either community
Aligners/matchers automate some work of an integration engineer, but can’t 90+% solve a major “customer” problem
Without a robust mediator, there aint no customer!
Lesson: Touch the end users, downstream
(someone outside the IT dept)
95% reduction in their work as schemas evolve
Generate code for end users 80% faster

14. Summary Two communities addressing similar problems
More standards, cleaner formalisms on S Web side
More pragmatics and richer suites on the db side
Largely formalism independent, could be imported, esp. “Instant gratification”