[Ponder Source] 1a: "Definitions, Examples, Privacy and Security, Federation Protocol specification"

[michielbdejong]

I'm thinking about milestone 1c https://github.com/federatedbookkeeping/task-tracking/blob/main/ngi-assure-application.md#milestone-1-theoretical-groundwork-and-requirements-analysis and how we could have live data that also gets translated on the fly. In my head I'm calling this idea "Liquid Data", with a ;) to both Live Data and Solid Data.

Like Live Data, Liquid Data can move anywhere, and in that's sense it's the opposite of Linked Data which uses URLs and adheres to the "Cool URIs don't change" mantra of the WWW.

[michielbdejong]

I wrote some brainstorm on hackmd, a slidedeck and a blogpost and since then my thoughts have moved on a bit towards "OAuth for multi-homed resources" and "software as a symptom" as catchphrases for what I think should be the next step for data portability.

[michielbdejong]

Still thinking a lot about this, also in conversations with Solid Data Modules, Braid, and various P4P projects.

There are a number of layers that come into play when you want to achieve software interoperability with multi-homed data, optionally also allowing multi-user edit. For instance multiple world views, access policies, trust, polyglot network, etc. Not all layers are relevant in all cases.

[michielbdejong]

There are also a number of recurring solution patterns, like Signature Chains for instance.

[michielbdejong]

git syncs the versioning of two or more filesystems, made up of folders with files, some of which consist of lines of text. A line of text is the smallest grain of data understood by git if you include its default merge algorithms (maybe it would understand other file types if you would plug in other merge operators).

liquid data is more semantic: it syncs the versioning of two or more relational databases. it also is more of a pluggable framework with a broader scope, and less of a single solution for just a few of the layers.

• db schema translation
• Local Resource Identifier (LRI) mapping
• db schema may or may not support contradictions, different merge algorithms depending on that
• policy / sub shares
• data transport (P4P etc), share key / author key, signature chains

[michielbdejong]

I should produce a deliverable from the hackmd, slide deck and further thought. Could take the form of a blog post, but much longer than https://michielbdejong.com/blog/30.html

[mcalligator]

Your coining of the term 'liquid data' is in close alignment with a blog post I published in April on the m-ld website. It discusses how m-ld enables multiple physically distributed data sources to become logically centralised without needing to create a physical central store for them.

[mcalligator]

I should produce a deliverable from the hackmd, slide deck and further thought. Could take the form of a blog post, but much longer than https://michielbdejong.com/blog/30.html

You should consider dating your blog entries so readers can get an idea of their recency.

[millette]

@mcalligator You just have to check the Last-Modified header to find out that's from Wed, 24 Apr 2024 12:28:59 GMT :-)

Seriously, totally agree! Having to dig for dates (in headers, rss, etc.) is cumbersome.