1 / 32

Conditions for Interoperability

Conditions for Interoperability. Nick Rossiter Michael Heather School of Informatics, Engineering and Technology Northumbria University nick.rossiter@unn.ac.uk http://computing.unn.ac.uk/staff/CGNR1/. Interoperability. Interoperability

keitha
Télécharger la présentation

Conditions for Interoperability

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. Conditions for Interoperability Nick Rossiter Michael Heather School of Informatics, Engineering and Technology Northumbria University nick.rossiter@unn.ac.uk http://computing.unn.ac.uk/staff/CGNR1/

  2. Interoperability • Interoperability • the ability to request and receive services between various systems and use their functionality. • More than data exchange. • Implies a close integration

  3. Motivations • Diversity of modelling techniques • Data warehousing requires heterogeneous systems to be connected • Semantic Web/RDF/Ontologies • GRID • MOF/MDA

  4. Figure 1: Classical ANSI/SPARC Architecture for Databases

  5. Suitability of Classical Architecture • Levels are not independent of each other • No universal closure of types • Need for interoperability: • Orthogonal type architecture • Formal mappings between the levels of the architecture • Natural closure of architecture

  6. 1st step – Identify Architecture Components and 2-way Mappings MetaMetaPolicy Meta Organize Classify Instantiate Concepts Constructs Schema Types Named Data Values Downward arrows are intension-extension pairs

  7. Formalising the Architecture • Requirements: • mappings within levels and across levels • bidirectional mappings • closure at top level • open-ended logic • relationships (product and coproduct) • Candidate: category theory as used in mathematics as a workspace for relating different constructions

  8. Choice: category theory • Requirements: • mappings within levels and across levels • arrows: function, functor, natural transformation • bidirectional mappings • adjunctions • closure at top level • four levels of arrow, closed by natural transformation • open-ended logic • Heyting intuitionism • relationships (product and coproduct) • Cartesian-closed categories (like 2NF): pullback and pushout

  9. Figure 2: More Detailed Interpretation of Levels in Category Theory: Natural Schema

  10. Forms of Interoperability • Semantic: • agreed concepts • a common framework of constructs • schema and data vary • e.g. working within a relational framework • Organisational: • agreed concepts (but open ended) • constructs, schema and data vary • e.g. working within an object framework

  11. (Organisational interoperability) Figure 3: Example for Comparison of Mappings in two Systems Categories: CPT concepts, CST constructs, SCH schema, DAT data, Functors: P policy, O org, I instance, Natural transformations: , , 

  12. Four Levels are Sufficient • In category theory: • objects are identity arrows • categories are arrows from object to object • functors are arrows from category to category • natural transformations are arrows from functor to functor • An arrow between natural transformations is a composition of natural transformations, not a new level

  13. Figure 4: Alternative Interpretation of Levels in the Architecture

  14. Godement Calculus • Manipulates categorical diagrams • Is a natural calculus • Provides rules showing: • composition of functors and natural transformations is associative • natural transformations can be composed with each other • Developed by Godement in 1950s • Has Interchange laws

  15. Figure 5: Godement Calculus in Barr and Wells (1990) 1st ed., p.96

  16. Equations (Figure 5) for Godement Calculus from Barr and Wells (1990) Equations (1)-(4): interchange, associativity and permutativity Equation (5): different paths o vertical composition

  17. Figure 6: Godement in Simmons, Lecture Notes on Category Theory, section 3.8

  18. Figure 7: Commuting Diagram in Simmons, Lecture Notes on Category Theory, section 3.8

  19. Application • Semantic Interoperability • Agreed concepts and constructs • Constant policy for mapping from concepts to constructs • Figure 5 – Barr & Wells approach • Organisational Interoperability • Agreed (but open ended) concepts • Variable policy for mapping from concepts to constructs • Figure 6 – Simmons approach

  20. Figure 8: Semantic Interoperability in terms of Godement Calculus. Constant Policy

  21. Figure 9: Organisational Interoperability in terms of Godement Calculus. Variable Policy

  22. Equations (Figure 6) for Godement Calculus from Simmons Equations (6) interchange, (7)-(8) associativity, (9) permutation, (10) different paths

  23. Technical Conditions for Interoperability • That our categories obey the rules of category theory • every triangle in the diagram commutes (composition) • order of evaluating arrows is immaterial (associativity) • identity arrows are composable with other arrows

  24. Anticipated Problems 1Type Information • Semantic annotation needed • To obtain metameta types from implicit sources • Needs open architecture • Agents have potential

  25. Anticipated Problems 2Composition Failure • Partial functions • Most categories are based on total functions • In real world many mappings are partial • not all of the source objects participate in a relationship (mapping) • Composition breaks down in a ‘total function’ category if a partial function occurs

  26. Figure 10: Punctured Commuting Diagram After Freyd (1990)

  27. Figure 11: Punctured Commuting Diagram for Library Example ACC = accessions, STK = stock, ISS = issues, CAT = catalogue

  28. Possible Advances 1: Develop New Category • Develop category of partial (lifted) functions • Lellahi & Spyratos (FIDE) • Enormous effort in basic category theory • Category theory is founded on total functions

  29. Possible Advances 2: Sketches • Use sketches • Relax composition rules for selected diagrams • Map graph-based sketch onto a category • Work by Rosebrugh, Diskin • Appealing for initial productivity • intuitively similar to ER modelling • But on fringes of category theory and lack flexibility and natural closure

  30. Preferred Advance • Avoid partial functions • Avoid such functions in design by greater use of roles • Convert all such functions into total ones: • map null relationships onto initial object (bottom)

  31. Figure 12: Non-punctured Commuting Diagram for Library Example ACC = accessions, STK = stock, ISS = issues, CAT = catalogue

  32. Summary • Formal four-level architecture promising for tackling interoperability: • Use of category theory in natural role • Structure through arrows (identity, category, functor, natural transformation) • Manipulate through Godement calculus • Problems: • Composition failure (particularly with partial functions) • Need semantic annotation

More Related