150 likes | 266 Views
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.
E N D
Context Interchange for Dynamic Services- Adaptability, 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.
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
Motivating example • 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!
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 • Performancewrt number of sources and the size of each source (query optimization issue) • Flexibility = Adaptability + Extensibility
Interoperate: hard-wired approaches (c) Internal standard approach Adopting a standard (a) BFS approach Brute-force between pair-wise sources 2 1 2 1 Internal standard 6 3 3 6 5 4 5 4 (b) BFC approach Brute-force between contexts 1 2 context_a currency: ‘KRW’; scaleFactor:1000 kind: base; format: yyyy-mm-dd 5 6 3 4 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
Concept: Length MetersFeet f() meters feet Shared Conversion Ontologies Libraries Context Management Administrator Context Mediator Source Receiver Context Context Select partlength From catalog Where partno=“12AY” part length Context Transformation Select partlength/.3048 From catalog Where partno=“12AY” Source 17 55.79 Auto-composition of conversions Receiver Interoperate: COIN Approach
Legend is_a relationship attribute modifier Ontology and conversion function 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 temporalEntity basic scaleFactor currency monetaryValue taxRate kind price organization Example source: src_turkey(Poduct, Vendor, QuoteDate, Price)
Demo – same context No semantic differences Meaningful data returned
Compose only relevant conversions (b e) (a) Select Vendor, Price From src_turkey Where Product=“Samsung SyncMaster 173P”; Conversion for scale factor (b) Select Vendor, QuoteDate, Price From src_turkey Where Product=“Samsung SyncMaster 173P”; Conversion for date format Conversion for scale factor
Auto-reconciliation for auxiliary source(b f) Introduced because of context difference in auxiliary source
Mediated query (b a) Date format for receiver Price definition – remove tax Scale factor Date format for auxiliary source olsen Currency
Flexibility and Scalability • Why other approaches cannot fully benefit from general purpose conversion? • the decision whether to invoke the conversion is in the conversion program Need to update/add many conversion programs Not flexible Flexible Update the declarative knowledge base.
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
Conclusion • Semantic differences cannot be standardized away • Must be flexible and scalable • COIN is a good solution • Modularization, declarativeness • Automatic composition of necessary conversions