1. Context Interchange for Dynamic Services - A daptability, extensibility, scalability analysis Hongwei (Harry) Zhu Stuart Madnick MIT Sloan School of Management {mrzhu, smadnick}@mit.edu http://interchange.mit.edu/coin WEB ‘04, December 11, 2004, Washington, D.C.

2. 2 Characteristics of services  Large number of sources –Online travel services –Comparison shopping services  Diverse user needs –Increasing usability with personalization  Cannot establish a single data standard  Must get semantics right –Adaptability, extensibility, scalability

3. 3 Motivating example Semantic aspectNumber of distinctions Currency10 different currencies Scale factor3 different scale factors: 1, 1K, 1M Price definition3 different definitions: base, base+tax, base+tax+SH Date format3 different formats, mm/dd/yyyy, dd-mm-yyyy, yyyy-mm-dd  Online comparison shopping – 400 vendor sources in different countries; 270 potential contexts – Different semantic assumptions in data – Compare prices in the context of any source chosen by the user  Need many conversions - 159,600 of them!

4. 4 Desired properties  Adaptability –Capability of accommodating changes in sources  Extensibility –Easy to add/remove sources  Scalability –Effort of enabling interoperation wrt the number of sources and the size of ontology –Performance wrt number of sources and the size of each source (query optimization issue)  Flexibility = Adaptability + Extensibility

5. 5 Interoperate: hard-wired approaches (a) BF S approach Brute-force between pair-wise sources (b) BF C approach Brute-force between contexts 12 6 54 3 1 2 6 54 3 Internal standard (c) Internal standard approach Adopting a standard 12 6543 context_b currency: ‘TRL’; scaleFactor:1e6 kind:base+tax; format: dd-mm-yyyy context_a currency: ‘KRW’; scaleFactor:1000 kind: base; format: yyyy-mm-dd context_c currency: ‘USD’; scaleFactor:1 kind:base+tax+SH; format: mm/dd/yyyy

6. 6 Interoperate: COIN Approach Context Mediator Source Receiver Context Conversion Libraries Source Context Shared Ontologies Context Transformation Context Management Administrator Concept : Length Meters Feet f() meters feet 17 part length Select partlength From catalog Where partno=“12AY” 55.79 Auto-composition of conversions Select partlength/.3048 From catalog Where partno=“12AY”

7. 7 Ontology and conversion function monetaryValue price temporalEntity basic kind currency is_a relationship attribute modifier Legend context_a currency: ‘KRW’; scaleFactor:1000 kind: base; format: yyyy.mm.dd context_b currency: ‘TRL’; scaleFactor:1e6 kind:base+tax; format: dd-mm-yyyy context_c currency: ‘USD’; scaleFactor:1 kind:base+tax+SH; format: mm/dd/yyyy context_d is_a context_b scaleFactor:1e3 context_e is_a context_d Format: yyyy-mm-dd context_f is_a context_c Kind: base+tax format scaleFactor organization taxRate Example source: src_turkey(Poduct, Vendor, QuoteDate, Price)

8. 8 Demo – same context No semantic differences Meaningful data returned

9. 9 (a) Select Vendor, Price From src_turkey Where Product=“Samsung SyncMaster 173P”; (b) Select Vendor, QuoteDate, Price From src_turkey Where Product=“Samsung SyncMaster 173P”; Conversion for scale factor Conversion for date format Conversion for scale factor Compose only relevant conversions (b  e)

10. 10 Introduced because of context difference in auxiliary source Auto-reconciliation for auxiliary source (b  f)

11. 11 Detection and explication (b  a)

12. 12 Date format for receiver Price definition – remove tax Scale factor Date format for auxiliary source olsen Currency Mediated query (b  a)

13. 13 Flexibility and Scalability Need to update/add many conversion programs  Why other approaches cannot fully benefit from general purpose conversion? –the decision whether to invoke the conversion is in the conversion program Update the declarative knowledge base. flexible Flexible Not

14. 14 How COIN scales  Component conversions are defined for each modifier  Overall conversions are automatically composed by abductive reasoning engine  Composition via symbolic equation solver and a shortest path algorithm  Inheritance enabled

15. 15 Conclusion  Semantic differences cannot be standardized away  Must be flexible and scalable  COIN is a good solution –Modularization, declarativeness –Automatic composition of necessary conversions