Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1/19
API4KP Metamodel
API4KP Metamodel
A Meta-API for Heterogeneous Knowledge Platforms
T. Athan1 R. Bell2 E. Kendall3 A. ...
2/19
API4KP Metamodel
Outline
1 Scope of the Standard
2 Scenario: The Connected Patient System
3 Foundations: Monads and O...
3/19
API4KP Metamodel
Scope of the Standard
A Meta-API for Knowledge (Reasoning) Platforms (KPs)
A Meta-API is a
platform-...
5/19
API4KP Metamodel
Scope of the Standard
Languages in Scope
Knowledge Representation and Reasoning Languages
Resource D...
6/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System 0: Overview
Figure: A Distribute...
7/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System I: Streaming Data and
Query Resu...
8/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System II: CDS
A Clinical Decision Supp...
9/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System III: Case History
The system mai...
10/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System: Complete
Figure: A Distributed...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
A metamodel is a model about model...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
12/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Structures Needed in API4KP
The various knowledge representat...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
14/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
Well-Known Monads
Persistence: IO
Unordered without Multiplic...
15/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
NestedM: a monad based on the free M monad
The simplest examp...
16/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
API4KP Structured Knowledge Resources
The structure of API4KP...
17/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
General Data Formats Included in Heterogeneous
Language Envir...
18/19
API4KP Metamodel
Summary
Summary
The Connected Patient System scenario encompasses a
number of architectural paradig...
19/19
API4KP Metamodel
Summary
Thanks to
Roger Burkhart
James Odell
Ed Skoviak
Ralph Sch¨afermeier
Bobbin Teegarden
Evan W...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
11/19
API4KP Metamodel
Scenario: The Connected Patient System
API4KP Metamodel: Classes
Entities in the universe of a KP f...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
13/19
API4KP Metamodel
Foundations: Monads and OBDA Mappings
What is a Monad (in Functional Programming?
Endofunctor on th...
Upcoming SlideShare
Loading in …5
×

RuleML2015: API4KP Metamodel: A Meta-API for Heterogeneous Knowledge Platforms

1,288 views

Published on

API4KP (API for Knowledge Platforms) is a standard
development effort that targets the basic administration services as
well as the retrieval, modification and processing of expressions in
machine-readable languages, including but not limited to knowledge
representation and reasoning (KRR) languages, within heterogeneous
(multi-language, multi-nature) knowledge platforms. KRR languages of
concern in this paper include but are not limited to RDF(S), OWL,
RuleML and Common Logic, and the knowledge platforms may support
one or several of these. Additional languages are integrated using mappings
into KRR languages. A general notion of structure for knowledge
sources is developed using monads. The presented API4KP metamodel,
in the form of an OWL ontology, provides the foundation of an abstract
syntax for communications about knowledge sources and environments,
including a classification of knowledge source by mutability, structure,
and an abstraction hierarchy as well as the use of performatives (inform,
query, ...), languages, logics, dialects, formats and lineage. Finally, the
metamodel provides a classification of operations on knowledge sources
and environments which may be used for requests (message-passing).

Published in: Technology
  • Be the first to comment

  • Be the first to like this

RuleML2015: API4KP Metamodel: A Meta-API for Heterogeneous Knowledge Platforms

  1. 1. 1/19 API4KP Metamodel API4KP Metamodel A Meta-API for Heterogeneous Knowledge Platforms T. Athan1 R. Bell2 E. Kendall3 A. Paschke4 D. Sottara5 1Athan Services (athant.com), West Lafayette, Indiana, USA 2Raytheon, Fort Wayne, Indiana, USA 3Thematix Partners LLC, New York, New York, USA 4AG Corporate Semantic Web, Freie Universitaet Berlin, Germany 5Department of Biomedical Informatics, Arizona State University, USA RuleML Symposium, Berlin, August 2015
  2. 2. 2/19 API4KP Metamodel Outline 1 Scope of the Standard 2 Scenario: The Connected Patient System 3 Foundations: Monads and OBDA Mappings
  3. 3. 3/19 API4KP Metamodel Scope of the Standard A Meta-API for Knowledge (Reasoning) Platforms (KPs) A Meta-API is a platform-independent model (PIM) for a family of APIs in specific languages, also called PSMs (platform-specific models). API4KP provides a PIM for the external APIs of KPs. Figure: A Monolithic KP Architecture.
  4. 4. 5/19 API4KP Metamodel Scope of the Standard Languages in Scope Knowledge Representation and Reasoning Languages Resource Description Framework (RDF) RDF Schema (RDFS) Web Ontology Language (OWL) Common Logic (CL) Event-Condition-Action RuleML (ECA) . . . Data Representation Languages Extensible Messaging and Presence Protocol (XMPP) JSON . . .
  5. 5. 6/19 API4KP Metamodel Scenario: The Connected Patient System The Connected Patient System 0: Overview Figure: A Distributed KP Architecture for Stream Processing, Clinical Decision Support (CDS) and Case History Storage.
  6. 6. 7/19 API4KP Metamodel Scenario: The Connected Patient System The Connected Patient System I: Streaming Data and Query Results Biomedical devices are available via pub-sub. Streamed data arrive in multiple formats e.g. XMPP, RDF Vocabularies are defined in RDFS, OWL, Common Logic (CL). Healthcare providers submit SPARQL queries through API4KP, receiving streamed incremental results, updated as new data arrive. Figure: A Heterogeneous Stream Processing KP Architecture.
  7. 7. 8/19 API4KP Metamodel Scenario: The Connected Patient System The Connected Patient System II: CDS A Clinical Decision Support System (CDS) is defined using event-condition-action (ECA) rules submited through API4KP, reacting to simple events (e.g. a vital parameter exceeding a threshold) complex events (e.g. a decreasing trend in the average daily physical activity) intervening with alerts and reminders. A failure of response (through API4KP) to an alert leads to escalation to another recipient. Figure: A Clinical Decision Support (CDS) KP Architecture.
  8. 8. 9/19 API4KP Metamodel Scenario: The Connected Patient System The Connected Patient System III: Case History The system maintains a stateful representation for patients qualifying for clinical pathways. Clinicians check for compliance with planned orders. As medical guidelines evolve, the logic of the pathway may need revision: queries to the patient’s history should be contextualized to whatever logic was valid at the time orders were placed. Figure: A Case History KP Architecture.
  9. 9. 10/19 API4KP Metamodel Scenario: The Connected Patient System The Connected Patient System: Complete Figure: A Distributed KP Architecture.
  10. 10. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes A metamodel is a model about models. Entities in the universe of a KP fall principally into these classes: Knowledge Sources - Models of the World Knowledge Environments - Models of Relationships Knowledge Operations - the Meta-API, Models of APIs Knowledge Events
  11. 11. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources : source of machine-readable information with semantics. Knowledge Environments Knowledge Operations Knowledge Events
  12. 12. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Mutable or Immutable (a.k.a Knowledge Resources) By level of abstraction (Knowledge Source Level) Basic or Structured Knowledge Environments Knowledge Operations Knowledge Events
  13. 13. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Knowledge T Environments : mathematical structure of mappings, where the domain and codomains of the mappings, called members of the knowledge environment, are instances of class T. Knowledge Operations Knowledge Events
  14. 14. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Knowledge Environments Knowledge Operations : functionality (possibly with side-effects. i.e. effects beyond the output value returned) having a knowledge source, environment or operation type in its signature. Knowledge Events
  15. 15. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Knowledge Environments Knowledge Operations Knowledge Events : successful evaluation or execution of a knowledge operation by a particular application at a particular time
  16. 16. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, e.g. the database of the Case History KP. Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources,
  17. 17. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, e.g. the OWL ontology in the Stream Processing KP. Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources,
  18. 18. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, e.g. the ECA rulebase in the CDS KP. Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources,
  19. 19. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, e.g. the input and output streams of the Stream Processing KP. Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources,
  20. 20. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, e.g. the effects generated by the CDS KP. Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources,
  21. 21. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, e.g. a failed communication from the CDS KP. Descriptions of state transitions for stateful Knowledge Sources,
  22. 22. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources, e.g. ECA simulations for protocol development.
  23. 23. 12/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Structures Needed in API4KP The various knowledge representations in the scenario require a variety of structures. Descriptions of I/O programs for persistent Knowledge Sources, Unordered collections for declarative Knowledge Sources, Ordered collections for order-prioritized Knowledge Sources, Concurrent sequences for streamed Knowledge Sources, Descriptions of side-effects for active Knowledge Sources, Failure-aware types for reliable Knowledge Sources, Descriptions of state transitions for stateful Knowledge Sources, In functional programming, monads have been created for each of these cases, providing a concept of equivalence that is isolated from side-effects and non-determinism, which is critical for conceptual modeling.
  24. 24. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] Satisfies the ”Monad Laws” has a ”unit” method to generate a simple instance of M[A] from some A has a ”join” method to flatten an instance of M[M[A]] to M[A] e.g. List[int].join( 1,2 , 3,4 ) = 1,2,3,4
  25. 25. 14/19 API4KP Metamodel Foundations: Monads and OBDA Mappings Well-Known Monads Persistence: IO Unordered without Multiplicity: Set Ordered with Multiplicity: List Concurrency: Future, Observable Side-effects: Task Failure: Maybe/Option/Try/Either State Transitions: State ...
  26. 26. 15/19 API4KP Metamodel Foundations: Monads and OBDA Mappings NestedM: a monad based on the free M monad The simplest example of a structure for knowledge resources is sets of sets. There is a set monad, Set[A]: a set whose members are of type A. NestedSet[B] = Set[B + NestedSet[B]] where B would be the type for Basic Knowledge Resource and + repsresents disjoint union, a.k.a. coproduct. But Set is just one particular kind of monad. For any monad M, we may define another monad NestedM: NestedM[B] = M[B + NestedM[B]] NestedM is related to the free monad of M through the equivalence FreeM[B] ≡ B + NestedM[B]
  27. 27. 16/19 API4KP Metamodel Foundations: Monads and OBDA Mappings API4KP Structured Knowledge Resources The structure of API4KP Structured Knowledge Resources can be any NestedM monad that is compatible with the semantics of its content. Details are available in the API4KP repository https://github.com/API4KBs/api4kbs/blob/currying/Monad_Trees.pdf
  28. 28. 17/19 API4KP Metamodel Foundations: Monads and OBDA Mappings General Data Formats Included in Heterogeneous Language Environments Knowledge Resources in API4KP include resources in formats without inherent semantics, such as XML, JSON or SQL, where the semantics is provided by mapping into knowledge representation and reasoning (KRR) language. The monadic character of structured knowledge resources allows environment mappings to be applied within the structure. To apply semantics, it is sufficient that the focus of a heterogeneous language environment be a KRR language. Further, mappings from KRR languages to data formats are useful in persistence, e.g. in a database.
  29. 29. 18/19 API4KP Metamodel Summary Summary The Connected Patient System scenario encompasses a number of architectural paradigms that should be addressed by API4KP. A monadic nesting structure has been created for compatibility with the diversity of semantic aspects illustrated in the scenario, including order, state, concurrency, side-effects, serialization and I/O. An extended concept of heterogeneous environment is employed in order to cover mapping between domain-specific data formats and knowledge representation languages. Outlook An initial submission of API4KP to OMG is anticipated in November 2015. Development of the metamodel will continue, with the specification of operations making explicit use of monads.
  30. 30. 19/19 API4KP Metamodel Summary Thanks to Roger Burkhart James Odell Ed Skoviak Ralph Sch¨afermeier Bobbin Teegarden Evan Wallace The DOL Committee ...
  31. 31. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Mutable or Immutable (a.k.a Knowledge Resources) By level of abstraction (Knowledge Source Level) Item - physical source, e.g. on hard disk or in memory Manifestation - concrete syntax, e.g. OWL axiom in Manchester syntax Expression - abstract syntax, e.g. OWL axiom Asset - equivalence class of Knowledge Expressions, with some equivalence relation e.g. logical equivalence Basic or Structured Knowledge Environments Knowledge Operations Knowledge Events
  32. 32. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Knowledge T Environments Member type T: Language, Format, ... Focused Preserving Knowledge Operations Knowledge Events
  33. 33. 11/19 API4KP Metamodel Scenario: The Connected Patient System API4KP Metamodel: Classes Entities in the universe of a KP fall principally into these classes: Knowledge Sources Knowledge Environments Knowledge Operations Actions (unary) Lifting, Lowering, Horizontal, Higher-Order, Void Idempotent Preserving Knowledge Events
  34. 34. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A]
  35. 35. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] , e.g. the type of lists with a generic parameter, List[A]
  36. 36. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] List is a monad List[int] is a monadic type 1,2,3 is an instance of type List[int]
  37. 37. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] has a map method allowing a function to be applied to each element of the list while preserving composition
  38. 38. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] has a map method allowing a function to be applied to each element of the list while preserving composition List[int].map( 1,2,3 , s → 2*s) = 2, 4, 6 List[int].map( 2,4,6 , s → s,2*s ) = 2,4 , 4,8 , 6,12 Exercise for the Reader: show List[int].map( List[int].map( x, f), g) = List[int].map( x, f o g )
  39. 39. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] Satisfies the ”Monad Laws” has a ”unit” method to generate a simple instance of M[A] from some A
  40. 40. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] Satisfies the ”Monad Laws” has a ”unit” method to generate a simple instance of M[A] from some A e.g. List[int].unit(3) = 3
  41. 41. 13/19 API4KP Metamodel Foundations: Monads and OBDA Mappings What is a Monad (in Functional Programming? Endofunctor on the category of types, A → M[A] Satisfies the ”Monad Laws” has a ”unit” method to generate a simple instance of M[A] from some A has a ”join” method to flatten an instance of M[M[A]] to M[A]

×