The document describes an API4KP metamodel for knowledge platforms. It defines key classes of entities in knowledge platforms, including knowledge sources, environments, operations, and events. Knowledge sources represent models of the world and can be mutable or immutable. Knowledge environments represent relationships between knowledge members. Knowledge operations represent functionality and APIs. The document also provides an example connected patient system to illustrate how the metamodel can represent different knowledge platform architectures for tasks like streaming data processing, clinical decision support, and case history storage. Foundational concepts like monads are discussed which can provide appropriate structures for representing different types of knowledge sources.

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/19
API4KP Metamodel
Outline
1 Scope of the Standard
2 Scenario: The Connected Patient System
3 Foundations: Monads and OBDA Mappings

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. 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. 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. 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. 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. 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. 10/19
API4KP Metamodel
Scenario: The Connected Patient System
The Connected Patient System: Complete
Figure: A Distributed KP Architecture.

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/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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 19/19
API4KP Metamodel
Summary
Thanks to
Roger Burkhart
James Odell
Ed Skoviak
Ralph Sch¨afermeier
Bobbin Teegarden
Evan Wallace
The DOL Committee
...

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