Closed phochste closed 10 months ago
Do we have a concrete use case to apply this one to?
Added some
Work in progress in Koreografeye project
@phochste Does this mean that you are actively working on this challenge?
Yes
Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!
@pheyvaer The Koreografeye is ready to be evaluated. It provides the functionalities of the acceptance criteria. What are the required steps to get into the new status?
@phochste The instructions are here. Can you also provide a link to the repo with the code?
Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!
Two examples repostories are added for Koreografeye how to use it:
All plugins have now a separate project:
https://github.com/eyereasoner/Koreografeye-Plugin
The documentation of Koreografeye was simplified to explain the essentials to get up and running:
Nice! For the challenge specifically, will you use a plugin in the demo that has something concrete instead of "some debugging output"?
@phochste Could you answer these two questions for the report? Thanks!
@pheyvaer
What were important technological decisions and assumptions you made?
The solution should be expected to be part of a larger existing framework. Koreografeye doesn't implement some features on purpose (like scheduling, rate limits, input and outputs, priorities etc). For these solutions there are already existing tools that can provide that. Koreografeye should be able to be just one added component to for instance an Apache Nifi installation.
Composition of Koreografeye parts such as input , orchestration an policy execution should be possible via the command line. The JavaScript API is just an added feature not the core of the design.
A lot of plugins could be created for policy enforcement and reasoner implementations. Component.JS was used to facilitate this.
Koreografeye makes a strict separation between reasoning and policy execution. We don't advise to create any side-effects in the reasoning part for two reasons:
The assumption that were made:
What are the lessons learned about your experience as a Solid developer?
Thanks! For the lessons learned can you explain more?
Solid application development is not only about web programming.
What else is in included?
Logic and reasoning can be external to your implementation.
And what is good/bad about this?
It is possible to provide very limited remote execution near or inside a Solid pod when logic and handling side-effects can be separated.
Is this good/bad? This reads more as a conclusion to the work itself. Unless I misunderstand what you mean.
remote server side Solid data management is in general not a solved issue.
What is missing? What is not solved?
Reminder @phochste
Solid application development is not only about web programming.
What else is in included?
For real Solid integration, processes need to be automated. Resources need to be made available, updated, delete also when no user is available, no web browser is opened. In a decentralized world, we can't expect that a Solid Pod will keep on adding logic to provide this automation steps. External services will provide this automation capacity.
Logic and reasoning can be external to your implementation.
And what is good/bad about this?
The good part of having logic external to your application is that programmers only need to worry about their own problem domain. E.g I want that linked data notifications that are send to my Pod are forwarded to my email address. This logic shouldn't be implemented by every Solid application in the work that send notifications to my Pod. What do they care what kind of extra business rules are required when an notification arrives in the LDN Inbox?
The bad part is like everything else in a decentralized world. When the logic is spread around many services:
It is possible to provide very limited remote execution near or inside a Solid pod when logic and handling side-effects can be separated.
Is this good/bad? This reads more as a conclusion to the work itself. Unless I misunderstand what you mean.
An orchestrator could in principle also run inside a pod. But most probably one wants to provide it very limited capabilities to prevent users to run arbitrary code on the pod server itself. E.g. an orchestrator that works only as an LDN Inbox rule engine like one has in Outlook or Thunderbird would allow only moving incoming notifications to a specific container.
remote server side Solid data management is in general not a solved issue.
What is missing? What is not solved?
We are currently depending on an authentication mechanism that only works for CSS (tokens). Every Pod implementation has its own mechanism to provide access tokens without needing to got a Web client every X minutes/hours/days.
Pitch
A Maintainer of a (Solid) LDN Inbox would like to see some automated processes happening when particular LDN Notification messages appear in one of her Inboxes or are being sent by the Maintainer. Possible automated processes include:
What should happen after receiving an incoming our outgoing message is described by an N3 rule book (rules). These rule books could require read access to the Pod (e.g. to check the existence of a resource on the Pod). E.g. a rule (using natural language just for the example):
The automated processes and rules are executed by an autonomous agent, the Orchestrator, on behalf of the Maintainer.
Desired solution
The desired orchestrator solution as the following pre-conditions:
What the orchestrator should do:
eye
reasoner are in focus)Extra concerns:
Acceptance criteria
A minimal demonstrator should:
Pointers
https://mellonscholarlycommunication.github.io/spec-orchestrator/
Scenarios
Typical use cases: