D1.1 – DROMEDAR Data Model Specification

As part of DREAM we are researching and developing data-models that enable peer-to-peer group collaboration.

The premise is that currently common ways of digitally capturing information are not well-suited for decentralized systems. Problems include:

  • Information is only stored in plain text / natural language. Relevant information can not be extracted and used efficiently.
  • Information is stored in application-specific serializations that is not usable beyond original scope (e.g. an application specific JSON schema).
  • It is hard to reference content. Either pieces of content do not have globally identifieable names or they are tied to centralized naming schemes (e.g. DNS).
  • Dynamically changing content (mutable content) either requires a centralized service or considerable amount of out-of-band coordination to prevent conflicts.

We intend to address these issues with four magic ingredients:

  • The Resource Description Framework (RDF): A simple, expressive and widely used graph-based data model.
  • Content-addressing: By using a cryptographic hash of the content itself as identifier of the content we can enable robust referencing of arbitrary content. Our contributions include a method for making RDF content-addressable as well as a robust and censor-ship resistant scheme for content-addressing.
  • Commutative Replicated Data Types (CRDTs): Distributed data-structures that ensure conflict-free merging of replicas.
  • Datalog: A query language based on Logic-programming that allows rich interaction and usage of data.

Components

For more information on the individual components please see the respective documents and/or Git repositories.

See also the GitLab group

Content-addressable RDF

TODO

Encoding for Robust Immutable Storage (ERIS)

TODO

RDF Signify

TODO

Distributed Mutable Containers (DMC)

Distributed Mutable Containers is a specification of distributed data-structures based on CRDTs.

Git Repository with specification and reference OCaml implementation.

2 Likes

Can these descriptions go in the road-map.org file?

/me

might be biased towards a text-only, offline-first form of such information.

I would really appreciate that this information stays here as it is our main mean of following up of the project, and it allows everyone to update and comment.
Also the first post of the descriptions is reproduced on the website.

Define “these”? The descriptions are copy-pasted from the proposal, so you might like to move them to the road-map.org but I cannot see why as it would only clutter the file. The idea is to evolve the first post into the deliverable itself: this is only a starting point framed from the original proposal, to keep it in mind.

Define “these”? The descriptions are copy-pasted from the
proposal, so you might like to move them to the road-map.org but
I cannot see why as it would only clutter the file.

Ok, fine with me.

I would really appreciate that this information stays here as it
is our main mean of follow up of the project, and it
allows everyone to update and comment.

Ok.

The idea is to evolve the first post into the deliverable
itself:
this is only a starting point framed from the original proposal,
to keep it in mind.

Ok. I’m fine with doing it like that.

I do want to point out that editing posts messes up my offline
view of
things (mail archives are not updated). But I’m fine with checking
into
Discourse.

What happens when a post is modified here? Do you get the new version, a notification of edition, or nothing?

What happens when a post is modified here? Do you get the new
version, a notification of edition, or nothing?

nothing :frowning:

OK so we should mention in a reply when we modify a post.

The idea is to evolve the first post into the deliverable
itself:
this is only a starting point framed from the original
proposal,
to keep it in mind.

Ok. I’m fine with doing it like that.

I think I need some further clarification. I don’t seem to grok
quite yet and might have been too fast to ok. Sorry.

I think it’s very valuable to keep a reference to the work here,
provide updates and discuss ongoing developments but I don’t see
how the first post can evolve into a complex document with
graphics, cross-references and bibliography (e.g. the ERIS
specification
).

Was the idea to write the entire specification document as edits
to a Discourse post?

Also related to
https://gitlab.com/public.dream/reporting/-/merge_requests/4

Define “these”? The descriptions are copy-pasted from the
proposal, so you might like to move them to the road-map.org
but
I cannot see why as it would only clutter the file.

Ok, fine with me.

While working on road-map.org I had to copy some descriptions (or
shorter versions) to the file, just so that I can make sense of
what is going on in road-map.org. I’d argue it declutters and
provides enough context to read and work-on road-map.org
stand-alone. wdyt?

1 Like

Yes, I appreciate the links from the road map to the Discourse, it helps a lot to keep things synchronized.

I replied to the publication part in D4.1 -- DREAM public collaborative website.

1 Like