Re: Introduction

Hi Niko,

TrustFlows is not relevant here, but happy to elaborate a little bit 
publicly to clarify:

TrustFlows is a high-level method (and thus not one specific framework 
or technology) we started adopting in our lab when we take on a new data 
engineering project. We’re going to explicitly model the writes, and 
going to create a specification on how a write needs to be processed 
towards multiple read resources. It’s basically what you could say that 
ActivityPub/ActivityPods does for social media data: i.e. an as:Like is 
processed in one view as an increment on a value that shows how many 
likes there are on a post, while it also flows towards other things. We 
want, in time, to make sure there is a more structured way to express 
such flows, as today, this is mainly expressed in specification text for 
developers to read. This method then has an effect on the architectures 
we build: we want to separate the concerns of policy checking and 
storing the actual data - for which you can read the whitepaper on how 
we want to tackle that here: 
https://solidlab.be/wp-content/uploads/2024/11/User-Managed-Access-Whitepaper.pdf 
- and we believe we somehow will need to be able to package triples 
within a trust envelope. The envelope should then be able to be 
referenced from i.e. a signature thus indicating unambiguously which 
triples it signed, or i.e. an ODRL policy that could indicate what 
precise triples it wants to be removed after a certain period of time...

Kind regards,

Pieter

On 22/11/2024 04:24, niko@nextgraph.org wrote:
> Hello everyone,
>
> Very pleased to meet you Pieter, and to see all the awesome work you 
> have done with your peers, on LDES, TREE, and Linked Data Fragments 
> that I think is also from the same people, and that I really like.
>
> Thanks for the invitation to participate on the future of TREE!
>
> On 21/11/24 10:55 am, Pieter Colpaert wrote:
>> [...] we will need to do conflict resolution and I think this should 
>> probably first be defined in this CG.
>
> Indeed, here we have gather specially for that!
>
> And I forgot to introduce NextGraph, which is a local-first (CRDT 
> based) quadstore (among other things), on top of which we offer (soon) 
> some Solid APIs, thanks to our collaboration with ActivityPods.org
>
> The CRDT we implemented is based on the paper "Synchronizing Semantic 
> Stores with Commutative Replicated Data Types" of Luis Daniel Ibáñez, 
> Hala Skaf-Molli, Pascal Molli, Olivier Corby.[1]
>
> By modifying the oxigraph [2] triplestore of Thomas Tanon to encode 
> the causal past of each SPARQL UPDATE, we can implement in NextGraph 
> the OR-set (Observed Remove Set) described in the paper.
>
> The conflict resolution is pretty straightforward : in case of 
> concurrent DELETE and INSERT of the same quad, the INSERT wins.
>
> We use the generic DAG of commits of NextGraph to encode the causal 
> relationship between SPARQL UPDATES, which is also end to end 
> encrypted, but that's not the topic here.
>
> Thanks to our implementation, we can offer a "time travel" feature 
> too, where each previous revision of any RDF Resource (a named graph), 
> can be queried, with SPARQL, just by entering the commit ID of the 
> SPARQL UPDATE representing the specific revision that we want to 
> query, as the named graph of that SPARQL QUERY.
>
> Hala Skaf-Molli, who is one of the authors of the paper, is present in 
> this very Community Group.
>
> Looking forward discussing this topic with you all !
>
> BTW, I am curious Pieter to hear more about "Trust Flows, 
> interoperability from write to read" that you presented recently. If 
> it is not relevant to the scope of this Community Group, feel free to 
> send me a personal email.
>
> Cheers,
> Niko
>
> [1] https://inria.hal.science/hal-00686484/document
>
> [2] https://github.com/oxigraph/oxigraph
>
-- 
https://pietercolpaert.be
+32486747122

Received on Friday, 22 November 2024 08:28:17 UTC