POD Agents (Github Actions for PODs)

[jeswr]

This is a placeholder - I will write it up in full soon. I've made a few notes for my own reference at https://gist.github.com/jeswr/7f28fb2bdab4408e8d861254e7e639d2.

Please also let me know if this is replicating something that is already being worked on.

Pitch

If there is a file ./agents.(ttl|rdf|xml|...) located in the ROOT of a users POD then the provider must negotiate with agents (that can either be on the web, or cached as a container in the POD provider) to perform background tasks according to well defined semantics.

Such tasks can include:

• An agent that hooks into given social media accounts mirrors changes to my POD and vice-versa
• An agent that hooks into POD data and calls an ambulance if data indicating a medical emergency is published (e.g. by a wristwatch)

This allows users/apps to declaratively define background processes that should be run on their POD.

Desired solution

Acceptance criteria

Pointers

Scenarios

[rubensworks]

Sounds similar to the orchestrators @phochste and @Dexagod are working on.

This might also be relevant to Jonni's work on automatic/periodic summary creation within pods.

[phochste]

Hi yes, in our Mellon project "Decentralized Scholarly Communication" we have a requirement an orchestrator component that automates things on pods. One needs to publish a rulebook document somewhere and instruct an orchestrator to execute these rules while watching the pod for triggers (e.g. based on resource changes or human triggers).

These rulebooks are currently written in Notation3 (executed by the EYE reasoner) and thats why I am very excited about your work @jeswr to bring that in to N3 !

[Dexagod]

The way it is phrased here, these tasks (e.g. pulling in social media data) seem to be orchestrated by the pod hosting service / the data pod itself. The current approach we have to orchestration, is having external agents (e.g. some service on your cellphone, some 3d party service, a script you run on your own server, ...) interact with your pod based on Linked Data Notifications. We have plans to extend the idea of orchestrators beyond what we currently have worked out for the scholarly communication usecase (nothing written out yet), but I think in the current vision we consider them to be external to the pod itself (e.g. your hospital / a 3d party runs a service that tracks your health data on your pod and gets notified of worrying patterns).

[pheyvaer]

@RubenVerborgh What changes are needed according to you?

[rubensworks]

Wrong Ruben? :-)

[pheyvaer]

Yes 😅 I mean @RubenVerborgh

[RubenVerborgh]

A challenge is a technical problem applied to a concrete use case with as output a demo. I'm missing the use case and demo parts.

[pheyvaer]

@jeswr Did you have the chance to look into making the necessary changes?

[jeswr]

Still in the process of properly figuring out the exact requirements for this challenge.

One alternative that addresses many of the same issues that I discussed with @RubenVerborgh last week was adding a read hook to Pod pods so that it is easier for a 3rd party agents like orchestrators to also observe when data is being read and act/intercept then (for instance to intercept the retrieval and add lazily generated data; whether it be rule-based inferenced data, inserting results of applying ML to a picture etc.)

[renyuneyun]

This sounds quite related to https://github.com/solid/specification/issues/393 (and also https://github.com/solid/specification/issues/390, about hooks).

The main difference is that the orchestrator (this proposal) seems to suggest each agent to do one specific task; while https://github.com/solid/specification/issues/393 assumes each agent to be capable enough to receive the "code" of the task and thus perform arbitrary tasks. But most things should be the same, and this difference should be easily adapted. In contract, https://github.com/solid/specification/issues/390 suggests that the Solid server handles and runs the hooks.

[RubenVerborgh]

Also see https://github.com/SolidLabResearch/Challenges/issues/68#issuecomment-1227788813