Playing it SAFE with RDF

As we’ve delved deeper into the world of SOLID and linked data in general, the benefits of self-describing data on the SAFE Network became obvious. If we want to enable users to have true control of their data, that data needs to be portable. And so some form of RDF data will be essential to ensuring that apps can pull in and work on data originally written via other apps.

Our recent foray into the world of WebIds, was enlightening to say the least, and the applications and data structures are a great jumping off point. And though working on these we had to solve a few issues relating to RDF on SAFE. Here I’ll cover a little on

RDF Serialisation on SAFE

RDF data is at its heart, a graph. You have your subject, object and predicate. You describe what your data is using vocabularies, which can be cross referenced to ensure we’re all talking about the same thing.

And RDF data has many serialisation formats. Turtle, if you’re storing it in a text file, JSON-LD if you’re sending it across the web using standard web friendly APIs.

But what about on SAFE? We have Immutable Data, which could be a fine representation if we don’t want to modify the data ever.

But as we’ve been looking at WebIds, and Linked Data containers (which we’re using for publicNames containers, for eg ), a large part of how the data will usefully function on the network will revolve around mutability.

And so we settled on Mutable Data (MD).

Now MD is a key:value store, and so we need a key:value serialisation to save the data to the network. For this we chose to use JSON-LD.

What’s in an RDF MD

While we’re aiming to setup fully linked data in SAFE, we don’t yet have a Content Addressable System to allow anyone to easily reference a specific data/type tag. And so, where it’s feasible (for webId MDs), we’re using the publicName system to help. And where this doesn’t make sense, we’re currently serialising the RDF graphs as a MD value, with the key being the graph’s @id.

Working with RDF on SAFE

To make everyone’s lives easier (including our own), we setup up some simple RDF emulation in safe_app_nodejs. This uses RDFlib.js to parse data and serlialise it ready for our MD. It also provides a nice flexible interface for converting that data into your desired serialisation format, so you can work in whatever way suits you best.

Setting up your RDF can be done thus:

const md = await authedApp.mutableData.newPublic(xorname, TYPE_TAG);
await md.quickSetup({});
const rdf = await md.emulateAs('rdf');

// do things

//commit the rdf mutable data to the network (and optionally encrypt that data.)
const toEncrypt = false;
rdf.commit( toEncrypt ) 

To populate an existing MD:

// populate the graph with data from the network (if an MD at <xorname> already exists...)

The full api can be seen in the repo. And as it’s stabilised, we’ll provide some more serious documentation.


I am attempting to read the _public and _publicNames (encrypted) containers as RDF.

Consider the following example:

const cont = await app.auth.getContainer('_publicNames');

const rdf = cont.emulateAs('RDF');
await rdf.nowOrWhenFetched();

// rdf.serialise('application/ld+json'));

The above works for _public, but for _publicNames it gives:

1023: No ID has been found in the RDF graph.
at module.exports (node_modules\@maidsafe\safe-node-app\src\native\_error.js:32:10)
at RDF.nowOrWhenFetched (node_modules\@maidsafe\safe-node-app\src\api\emulations\rdf.js:100:13)
at <anonymous>

The error is thrown by nowOrWhenFetched.

I guess this is because the _publicNames container is encrypted.

Any help appreciated, @joshuef and @bochaco!

1 Like

I think that’s correct @bzee, I have noticed this as well while working on fixing some of the tests, if you have the chance please report it on github mentioning this is for the dev branch.

1 Like

Thanks a lot for confirming! I will report this along with the other issues that I put in a PM as soon as I can access GitHub again.

GitHub being down sucks! Time for SAFE Git! :smile:

Edit: Managed to submit the issues!