2022-06

https://josd.github.io/Talks/2022/06welding/

by Jos De Roo of KNoWS office of IDLab - Ghent University - imec.

The GPS4IntegratedCare project
objective is **Automatic generation of dynamic and personalized care workflows**

Technologies used:

- Semantic Web Language (JSON-LD, Turtle, N3)
- Reasoning Engine (EYE)

Goal driven Parallel Sequences (GPS):

- Inspired by Linear Logic
- "In linear logic we are instead concerned with the change of truth with a change of state. We model this in a very simple way: when an inference rule is applied we consume the propositions used as premises and produce the propositions in the conclusions, thereby effecting an overall change in state."
- Implemented in GPS plugin for EYE

The project worked out fine, but the architecture is centralized around a single smart workflow engine and that is really not scalable.

The proposal is to address the scalability with MAP

Multi-Agent Proofs (MAP):

- Multiple agents can work together by using their own knowledge/logic/data and proofs made by other agents.
- The proofs are guaranteeing a transparent and accountable way of working and they only disclose what is relevant, so there is no need to have an "All knowledge is contained in here" (what I learned from Tim Berners-Lee).

This is just a proposal with a proof of concept in which agent1 and agent2 are GPS agents and agent2 reaches his goal thanks to the lemmata made by agent1.

Agent2-proof makes use of lemma9 from Agent1-proof

<#lemma13> a r:Extraction; r:gives { <http://josd.github.io/eye/reasoning/map/agent1-proof.n3#lemma9> a r:Inference. }; r:because [ a r:Parsing; r:source <http://josd.github.io/eye/reasoning/map/agent1-proof.n3>]. <#lemma14> a r:Extraction; r:gives { <http://josd.github.io/eye/reasoning/map/agent1-proof.n3#lemma9> r:gives { :map-BE gps:description ({:i1 :location :Gent} true {:i1 :location :Brugge} :drive_gent_brugge 1500.0 0.006 0.96 0.99) }. }; r:because [ a r:Parsing; r:source <http://josd.github.io/eye/reasoning/map/agent1-proof.n3>].

The burden of proof is now on the server:

- the server has to find out why he should do the job for the client
- but there is no omniscient server

Reverse the burden of proof:

- the client provides a proof
- the server checks that proof
- if the proof is fine the server does the job for the client

This is much more scalable but requires client side reasoning + proof generation

The proof could be provided as HTTP GET payload