# Brainstorm voor paper mepdaw
Topic: Event Sourcing

## Scope

* how to store large amounts of data on a solid pod

* Event log/ Event Source paradigm for solid
* append only log

### Problem space:

Two approaches

- No history in default solid protocol.
- Can be overcome implementation wise with some sort of memento -> i.e. LDP with memento
- How do applications in solid/LDP deal with a large amount of similar data
- Application specific strategies, follow the protocol that an application sets -> bad for interop
- Unfortunately this means that only your application will be able to understand your data. not good
- create a resource in a container for each new event
- PATCH one big resource

**Als je iets met uw data later wilt doen, wordt het juist interessant om een event source te hebben als basis**

* REad-write strategy in het algemeen dat we willen aankaarten: *Dit hebben we geleerd uit de demo?*
* Probeer zo zwaar mogelijk semantisch te schrijven zodanig dat we zoveel mogelijk interop te garanderen e.g. derived resources
* makkelijk om van ssn/sosa model te gaan naar schema.org, maar niet altijd mogelijk om van simplistisch schema.org direct naar ssn/sosa te gaan (hoe moeten we schema.org interpreteren)
* Gelijkaardig probleem over hoe te schrijven
* long vs short is goed voor bepaalde applicaties
* we zoeken een schrijf strategie zodat we best de view genereren
* Voor bepaalde applicaties zouden we liever vele kleine resources hebben en voor andere lange grote -> met een event source is het mogelijk om dit aan te bieden

Compare lots of POSTS on an LDP server vs lots of PATCHES on server -> delay (y-axis), # message (x-axis)

#### Other domains?

* Iot -> temperature readings
* medecine and health -> heart monitoring (maybe ask Stijn for more input)
* location data

### What is not solved

-> base container where to write

-> dealing with sharing parts of your data protocol

-> derived views of raw data

-> schema alignement?

## Other works

* A Solid-based Architecture for Decentralised Interoperable Location Data

* https://wise.vub.ac.be/index.php/publication/solid-based-architecture-decentralised-interoperable-location-data
* https://github.com/OpenHPS/ipin2022-solid/
* Doen ook aan locatie opslaan, maar implementeerden alles PATCH based -> doe testen met locationmapper die aantonen dat patch based voor een groot volume niet te doen is. (e.g. gpx file van boottocht)

* **TailR**: A Platform for Preserving History on the Web of Data

* https://dl.acm.org/doi/pdf/10.1145/2814864.2814875

* Open source repo: https://github.com/pmeinhardt/tlr

* Andere manieren om updates bij te houden in RDF

* Changeset: This vocabulary defines a set of terms for describing changes to resource descriptions http://vocab.org/changeset/schema.html
* Graph Update Ontology: provides an OWL
vocabulary for graph changes which avoids RDF reification
* http://purl.org/hpi/guo#
* RDF Patch: RDF Patch is a file format for recording changes made to an RDF dataset https://afs.github.io/rdf-patch/
* Delta: ontology of differences between RDF graphs: https://www.w3.org/DesignIssues/lncs04/Diff.pdf

* SemVersion: provides versioning for **RDF models/ontologies** based on structural and semantical deltas: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.217.84&rep=rep1&type=pdf

* R&Wbase: Git for triples: Praat in **future work over versioning in LDP** https://ruben.verborgh.org/publications/vandersande_ldow_2013/

* Heeft samen met R43ples shortcomings volgens dit artikel

* > There are two common model alternatives in revision con-
> trol systems: snapshot storage and delta storage.

* Specifying, Monitoring, and Executing Workflows in Linked Data Environments ?? TODO read

* https://link.springer.com/chapter/10.1007/978-3-030-00671-6_25

* DDIA: chapter 11 about event sourcing

* LDP-DL: A language
to define the design of Linked Data Platform

* https://www.emse.fr/~zimmermann/Papers/eswc2018.pdf
* second, we want to generate LDPs that supports paging [19], which is a desired feature for large datasets
* https://www.w3.org/TR/ldp-paging/

Context:      Why the need is so pressing or important
For Knowledge Graphs expressed in the RDF model,
a~common practice is to offer a~document-based API
that distributes RDF~triples across documents
in categories
in a~certain domain-specific way.
Such organizations are not uniquely determined:
depending on the use case and the application consuming the knowledge,
different structures might be beneficial or even necessary.
% Need:         Why something needed to be done at all
While servers can rely on technologies such as Linked Data Event Streams (LDES)
to make the same graph \emph{readable} in multiple organizations,
challenges arise when clients need to \emph{write} to such derived %collections.
Task:         What was undertaken to address the need
We have developed the \emph{LDES~Write} protocol~\rv{?},
compatible with the Linked Data Platform (LDP) specification,
to instruct clients how to perform write operations to RDF~document collections.
Object:       What the present document does or covers
\phrasing{%
This article presents an overview of LDES Write,
suggests a~possible architecture,
and explains how to read and write materialized views.
}
Findings:     What the work done yielded or revealed
\rv{So what have we found? If you do XYZ, then clients can\ldots}
Conclusion:   What the findings mean for the audience
\rv{So what did we learn from this? What insights do we want to share with people? When should they use LDES and when not?}
Perspectives: What the future holds, beyond this work
\rv{How can people build upon our work?}