mielvds
commented
3 years ago This is ISSUE6 in the Orchestrator spec and already discussed a bit in our weekly meetings.
In our reasoning we assume that a resource change is about one resource on a pod. In reality how could Solid inform us about these scenarios? Can Solid give us more control about state changes than other LDP implementation in general?
Not really. Although the https://github.com/solid/community-server has a websocket implementation, but I'm not sure wheter it can be used for that or will be part of the Solid protocol.
Adding a new resource to pod
* We need to observe the state of a Container for `Last-Modified` , `ETag`? * And match the Container against a previous cached version?
Yes, and probably that's taking it too far?
Updating a resource on the pod
* We need to observe the state of a specific resource for a `Last-Modified`?
Yes, and compare it to the last time we checked it.
Deleting a resource from the pod
It's deleted from the container, but not necessarily from the pod. A watched resource delete would be checking for a 4XX I guess.
* We need to observe the state of a Container for `Last-Modified` , `ETag`? * And match the Container against a previous cached version?This is all very much tight to the versioning of data on the pod and not trivial:
* Artefacts are complex objects
Sometimes, yes, but the exchange network does not deal with this. The artefact is the smallest possible unit. There are only artefacts that might have links to other artefacts. That's all it should know, no?
* Need something like [OAI-ORE](http://www.openarchives.org/ore/ ResourceMap to define the boundaries of a resource
ORE could be a way to provide those links, but any LD doc could do.
* Sub-resources of an artefact can be added, updated, deleted
So given what I say above, I don't think there should be sub-resources, at least not from our project's perspective.
* Sub-resources be linked data resources where triples can bed added, updated, deleted
Or just other artefacts?
* Do we need to track what changes so that an orchestrator know what to do?
Very good question and I'm starting to wonder whether watching resources is a good idea. That said, we need a way to pick up important changes to the pod that did not originate from the Dashboard or the Orchestrator.
- E.g. send an email when the `dc:status` field of Artefact1/metadata.rdf changed to `published`
That's quite granular. I'd say that the trigger can only tell you Artefact1/metadata.rdf has changed. The condition ?s dc:status "published" would be defined in the rule?
Dexagod
This is ISSUE6 in the Orchestrator spec and already discussed a bit in our weekly meetings.
In our reasoning we assume that a resource change is about one resource on a pod. In reality how could Solid inform us about these scenarios? Can Solid give us more control about state changes than other LDP implementation in general?
Adding a new resource to pod
Last-Modified,ETag?Updating a resource on the pod
Last-Modified?Deleting a resource from the pod
Last-Modified,ETag?This is all very much tight to the versioning of data on the pod and not trivial:
dc:statusfield of Artefact1/metadata.rdf changed topublished