The need for the read-write Linked Data Web is currently implemented as a Create, Read, Update or Delete (CRUD) strategy on resources, which implies that agents will read exactly what has once been written. In practice, however, deploying writeable Linked Data nodes in an ecosystem reveals the following problems. Data reuse is hindered as later data usage requirements diverge from how the data was originally written, as well as by evolving data models. Moreover, the absence of an authoritative source to guarantee auditability forces individual data point verification at the read side. We present key characteristics of writeable Linked Data nodes (cope with longevity for written data, combine read data using diferent models, and provide an explicit trust context) as arguments justifying the need for a more complex operational model. We apply a Command Query Responsibility Segregation pattern to decouple write and read interfaces, introduce semantic mappings within the writeable Linked Data node to support evolving data read requirements, and apply Event Sourcing aligned with PROV-O's Actor-Entity-Activity model to provide an explicit trust context. We term this operational model “Trustflows”. Applied to the PACSOI use case, Trustflows showcases the additional afordances of handling data coming in diferent granularities, from diferent sources, adhering to diferent reading requirements.
The need for the read–write Linked Data Web [
writeable Linked Data node: an online storage service that publishes Linked Data, where that Linked Data can be created and edited by multiple (authorized) actors in an ecosystem.
However, these current initiatives apply writeable Linked Data nodes through (authenticated and
authorized) PUT, POST, and DELETE requests on the same RDF-based HTTP resources available for
GET today. This follows the Create-Read-Update-Delete (CRUD) operational model, deemed simple
and efective for the majority of applications [
Whilst applying writeable Linked Data nodes in various R&D projects in domains such as Circular Economy (in the Horizon Europe Onto-DESIDE project), HR (in the imec.icon SHARCS project), and health (in the imec.icon PACSOI project)2, we encountered the following exemplary problems. • In the Onto-DESIDE project, a product’s material composition is shared in a diferent granularity than how it is stored: only whether certain chemical substances exceed defined thresholds must be shared, not the exact quantitative concentrations3. This currently requires a parallel process to continuously keep the derived data summary up to date with the product details. //www.imec-int.com/en/research-portfolio/pacsoi. LGOBE CEUR
ceur-ws.org • In the SHARCS project, reading diploma credentials written using the European Learning Model (ELM) v3.2 requires a substantial processing step by every new client application that uses ELM v3.34, which severely limited the reusability of the published Linked Data, even though Semantic standards were meticulously followed. • In the PACSOI project, the source of a data write such as a weight measurement – whether obtained from a calibrated sensor or entered manually – influences its suitability when being read for diagnostic purposes.
In this paper, we examine how certain characteristics of writeable Linked Data nodes give rise to specific requirements (Section 2), which conflict with the symmetric read-write approach. We further propose an alternative operational model (Section 3) named Trustflows , by applying Command Query Responsibility Segregation (CQRS) and Event Sourcing to Linked Data, thus enabling a write-to-read Web of Data: a transparent pipeline from data writes with an explicit trust context mapped to evolvable data reads. We validate this approach by applying it to the PACSOI project’s use cases.
implies the requirements of coping with longevity and decentralization. The assumption is
that adding the complexity of Linked Data publishing (compared to regular data publishing, e.g., via
JSON:API [
implies the requirement of an explicit trust context. Typical Linked Data nodes act as an authoritative source, i.e., the actor governing the node is assumed to reassure the published data is accurate. Once multiple actors are allowed to write data – even with security measures such as a trusted registry in place – the implicit trust context of a single authority is no longer valid. Each read’s individual data point must be verified separately, which introduces a large processing overhead. Alternatively, an explicit trust context allows clients to determine which data came from which writing actor. This allows moving the verification from individual data points to writers, which improves eficiency. CRUD provides no guidance for providing such an explicit trust context. If we take the 4Changes, among others, included the change of the ontology base uri: https://op.europa.eu/en/web/eu-vocabularies/dataset/ -/resource?uri=http://publications.europa.eu/resource/dataset/snb-model.
PACSOI exemplar, not only the data values (i.e., the weight measurements) are important, but also the type of event they originated from (e.g., were they measured via a scale, manually entered, or calculated), and from which actor they originated (e.g., from a calibrated scale, from a healthcare provider, or via self-assessment).
Foremost, we argue that fit-for-purpose authentication and authorization must be put in place: a complementary task that is required for any data exchange use case.
To cover R1 and R2, we decouple the write interface from the read interface, at the cost of
increased complexity. A mature operational model is Command Query Responsibility Segregation
(CQRS) [
To cover R3, we make the trust context explicit for every data write. For this, we can apply the
Event Sourcing design pattern [
The imec.icon PACSOI project (2024–2026)5 aims to leverage Solid‑based decentralized “pod” (i.e., an implementation of a writeable Linked Data node) and Linked Data technology to give patients control over their health data while enabling scalable, privacy-preserving federated analytics, initially demonstrated in a proof‑of‑concept (PoC) focused on follow-up of patients that underwent bariatric surgery (Figure 1). The following use case is investigated.
As a patient, I write all my weight measurements (done by healthcare providers, through a ByteFlies smart scale, and via a questionnaire in the MoveUP application) to my personal data storage, governed by the FAQIR Foundation. My healthcare providers can use these measurements to check my progress, and simultaneously, my measurements are aggregated into cohorts to be used in research, e.g., by pharmaceutical players.
Our PoC for this use case uses data from 12 sources (i.e., smart scales, questionnaires, and physiological measurements), provided by medical sensors, for 200 patients.
The authentication and authorization information during a write operation captures the Actor part
of the Actor-Entity-Activity model. Mature authentication specifications (e.g., OpenID Connect [
The write operation’s body data – adhering to the Event Sourcing design pattern – captures the Entity-Activity part of the model. We explicitly store the trust context linked with the data events (i.e., 5https://www.imec-int.com/en/research-portfolio/pacsoi
Smart Scale
App
Event Sourcing (Actor: , Entity: ,Activity: ) HCP manually measured weight
93.46kg on 4/5/25 Smart Scale measured weight 92.9kg on 7/5/25 at 8:03 93.0kg on 8/5/25 at 7:59 92.7kg on 9/5/25 at 9:49 Patient entered weight 200lbs on 11/5/25 at 23:12:04
CQRS (Commands: , Queries: , Explicit mappings: )
KG + mappings
Patient lost 2.7kg at 11/5
Patient lost 0.8kg at 9/5 (calibrated)
Average cohort evolution
the entire Actor-Entity-Activity model) in an event log. For storing such enriched data events, we can
apply approaches such as Linked Data Event Streams [
Mappings (e.g., through SPARQL CONSTRUCT queries, potentially enhanced with ontology alignment mappings, entailment reasoning, or other established Linked Data mapping techniques) allow customizing the reads based on performance requirements (e.g., provide a “last thirty days” overview per patient), data model requirements (e.g., provide a long-term trend across patients), and trust requirements (e.g., only include measurements taken by a calibrated smart scale).
This paper argues that the demands of real-world read-write data processes have diferent underlying assumptions and requirements than those currently provided by read-write Linked Data systems. From an analysis of concrete demands from use cases, we propose a more fitting operational model that leverages CQRS with explicit semantic mappings and Event Sourcing. We performed an initial validation of our Trustflows operational model within the PACSOI project, showing how the Trustflows operational model can handle data coming in diferent granularities, from diferent sources, and adhering to diferent reading requirements. This work is an initial presentation, and will benefit from discussion and feedback from the broader community. By further investigating common pitfalls of deploying writeable Linked Data nodes, we will research a more concrete specification and accompanying implementation that aligns with the current state of the art, brings support for our aforementioned requirements, and avoids the broader set of pitfalls.
The described research activities were supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10), and by the imec.icon project PACSOI (HBC.2023.0752), which is co-financed by imec and VLAIO and brings together the following partners: FAQIR Foundation, FAQIR Institute, MoveUP, Byteflies, AContrario, and Ghent University – IDLab. We thank all partners in the following projects, as their contributions helped to shape the requirements: imec.icon SHARCS and Horizon Europe Onto-DESIDE.
During the preparation of this work, the author(s) used GPT-4o to: Grammar and spelling check. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.