Javascript RDF Tooling ideas

rdf

#1

On and off over the past weeks, I’ve been playing around with what I feel could be a better web dev workflow for RDF / JS. posted over on the solid forum too, for anyone wanting to comment in a SOLID context

This is somewhat built atop the previous 'improving APIs" preRFC. I’ve built out some proof of concept tools which could be sued together, along with JS module schema definitions to make writing RDF that bit simpler:

I’ve set about defining schemas as JS modules. The aim being that we can then use these at run time to provide feedback to devs / warnings etc, and provide validation.

So using a Book schema pulled from schema.org, using a POC lib for sheperding data

import shepderd from '../src/shepherd';
import { Book } from 'schema-doter';
import rdflib from 'rdflib';

const sampleObject = {
    'id'            : 'safe://here',
    'author'        : 'Josh',
    'publisher'     : 'Somebody'
};


let rdf;

rdf = await shepderd( sampleObject, Book );

// which means you can now use RDF lib to serialise / work on the graphs as you please.
rdflib.serialize( null, rdf, sampleObject.id, 'text/turtle', ( err, result ) =>
{
    console.log( result ) // Logs a turtle graph as a string
} );

The idea here is that the dev doesn’t actually need to worry about RDF that much. If you have data and want to ensure its portability, all you need is a schema for your data and you should be able to get going.

After choosing a vocab they can easily convert their data without having to worry about turtle/json-ld etc at all.

There’d be no URLs to be resolving for validating the schema once you’ve gotten your schema package installed (so this could work offline, eg).

Having a package available can allow for some validation checks and documentation to be generated for a given schema also.
So I’ve another proto-lib: https://github.com/joshuef/rdf-check-mate which could be hooked into a toolchain to throw warnings on invalid data types eg.

Validity:

// Checking against Book schema from schema.org
import { Book } from 'schema-doter';

const sampleObject = {
    'numberOfPages' : 4,
    'title'         : 'Dave',
    'author'        : 'me',
    'published'     : 'now',
    'publisher'     : 'yes '
};

valid = validate( Book, sampleObject );

// This warns in console:
//
// There is some incompatability between your provided object and the schema...
//  title , published do not exist on this schema

// But (potentially still...):
console.log( valid ) // true

Invalid:

const badObject = {
    'numberOfPages' : 4.1,
    'title'         : 'Dave',
    'author'        : 'me',
    'published'     : 'now',
    'publisher'     : 'yes '
};

valid = validate( Book, badObject );
console.log( valid ) // false

// also throws:
// Candidate data type error: 4.1 is number should be: Integer

All of which, I’m hoping could just make it that bit easier to get going with RDF. As above, that’s all proof of concept modules at the mo, but for me, it seems like a simpler way of getting folk to use RDF data, as there’s:

  • Less decision paralysis
    • no, schema serialisation to worry about…
    • if there’s limited vocab packages, it’s that much simpler to choose from popular ones, NPM etc can already act as a measure for this.
    • simpler to publish your own schema… as simple as an NPM package anyway…
  • Feedback!
    • Get warning or errors when attempting to parse invalid data.
    • Potential to provide/generate a simpler set of documentation for any schemas
  • Just use your JS, but with the potential for full RDF.lib objects / serialisation so you should be able to hook into any RDF styled apis easily enough…
    • An no need to get _into _ RDFlib and start wondering about literals etc…

Any feedback/thoughts on the above appreciated! :+1:


#2

Looks brilliant Josh, itching to play but no time for now :frowning_face:

I think someone said recently (on one of the Solid gitters IIRC) that the URI for an ontology doesn’t have to be resolvable. So you can just make them up. Seemed odd to me. Or is that something else?

I really like the look of this. :slight_smile:


#3

Yeh I saw that also somewhere recently :slight_smile:

Seems like it’s just a reference point for aligning the data more than a functional requirement to resolve it, indeed.

Here though I’m more meaning if you do need to grab the data (as some progs might), having it packaged with your app can make sense.


#4

@joshuef, in the second example, did you really mean this:

valid = validate( Book, {...badObject, numberOfPages: 4.2222}  );

or the following instead:

valid = validate( Book, badObject ) ;

…otherwise I don’t understand why it would fail in this case and just a warning in the previous one?


#5

I meant the latter indeed! will update. thanks