RDF can be a pain.
It’s great once you’ve got it, but figuring out just how to describe your data, given the myriad of schemas and vocabs out there (yay decentralisation!). It can be a pain.
For us, this is clearly one of the largest blockers to people implementing RDF data in their applications. And we want RDF on SAFE. It makes sense to have it. To keep data portable. To keep users owning their data. We want RDF and we want to make it hard to get it wrong.
Even just for our own sanity!
So as we were building out the POCs, we started creating some helper APIs to help simplify the process.
These are built atop the RDF Emualtion, we started creating APIs to abstract away the vocab-paralysis that can come with RDF, so when working with WebIds at least, it should be easy enough to get going.
A WebID Emulation
The WebId emulation makes creating a WebId profile document on SAFE, a simple function call:
const profile = {
uri: 'safe://mywebid.gabriel',
name: 'Gabriel Viganotti',
nick: 'bochaco',
website: 'safe://mywebsite.gabriel',
image: 'safe://mywebsite.gabriel/images/myavatar',
};
const md = await authedApp.mutableData.newPublic(xorname, TYPE_TAG);
await md.quickSetup({});
const webId = await md.emulateAs('WebID');
await webId.create(profile);
This will create an RDF graph, populate it with your profile, which itself will have vocab descriptions of the data consistent with other SAFE WebIds. It creates a publicName
and subdomain
if needed, and populates those with appropriate RDF graphs too.
For now the profile is limited to name
, nickname
, img
, website
, but there’s nothing stopping us expanding this as we move forwards.
On top of that, we’ve added a few more helpers to the WebID emulation, to make update
and serialise
a breeze too!
Working it on the Web
In order to make working with already existing WebIds simpler, we added another new top level API to safe_app_nodejs: the (oh so imaginatively named) ‘web’ api: safe.web
.
This features helpers for what could be more ‘normal’ SAFE tasks: createPublicName
, getPublicNames
, addWebIdToDirectory
, getWebIds
. (Bear in mind these will all generate RDF style versions of these containers, which are not currently compatible with older SAFE applications.)
The slightly ambiguous addWebIdToDirectory
is used to provide a simple way of seeing all webids owned by an account. This is used as part of the webId.create
emulation to save a reference to the webId’s URL to the public
container, providing us one easy place to retrieve all webIds without having to request permissions to _publicNames
, and then digging deeper into each public name to see if it is a webId or not. Saving us a couple of fetches.
The converse to this is the getWebIds
,which will return a list of all webIds stored in the ‘directory’, (aka. the public
container for now.)
All of these APIs are actively being used in both the Peruse POC and the WebId Manager.
More Help!?
That’s the last of the APIs we’ve added for the moment. But we’re aiming to provide as much help as we can to devs to help make adding RDF vocabs to their data, easy.
So comments, thoughts, PRs and suggestions are all suuuuuper welcome.