How observe resource state changes in Solid?

[phochste]

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

• We need to observe the state of a Container for Last-Modified , ETag?
  • And match the Container against a previous cached version?

Updating a resource on the pod

• We need to observe the state of a specific resource for a Last-Modified?

Deleting a resource from the pod

• 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
  • Need something like [OAI-ORE](http://www.openarchives.org/ore/ ResourceMap to define the boundaries of a resource
• Sub-resources of an artefact can be added, updated, deleted
• Sub-resources be linked data resources where triples can bed added, updated, deleted
• Do we need to track what changes so that an orchestrator know what to do?
  - E.g. send an email when the dc:status field of Artefact1/metadata.rdf changed to published

[mielvds]

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]

The fedora API also has an interesting take on this:
https://fedora.info/2018/11/22/spec/#notification-events

6.1 Notification Events §
For every resource whose state is changed as a result of an HTTP operation, there must be a corresponding notification made available describing that change.

[mielvds]

Websockets are also part of the solid spec: solid/specification#50 (comment)