1 / 15

Context Interchange for Dynamic Services - A daptability, extensibility, scalability analysis

This paper discusses the challenges and solutions in adapting online dynamic services, such as travel and comparison shopping. With an emphasis on adaptability, extensibility, and scalability, it highlights practical examples and the necessity of accommodating diverse user needs. It introduces a novel approach called COIN, which leverages a modular conversion system enabling seamless interoperation among various data sources. This method addresses the semantic differences inherent in data sources, proposing an automatic composition of conversions to enhance usability and performance across services.

whitley
Download Presentation

Context Interchange for Dynamic Services - A daptability, extensibility, scalability analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  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. 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!

  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 • Performancewrt number of sources and the size of each source (query optimization issue) • Flexibility = Adaptability + Extensibility

  5. 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

  6. 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

  7. 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)

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

  9. 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

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

  11. Detection and explication (ba)

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

  13. 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.

  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. Conclusion • Semantic differences cannot be standardized away • Must be flexible and scalable • COIN is a good solution • Modularization, declarativeness • Automatic composition of necessary conversions

More Related