Re: Toward easier RDF: a proposal

Dear all,

> At the
> same time, a painful reality has emerged: RDF is too hard for
> *average* developers.  By "average developers" I mean those
> in the middle 33 percent of ability.

A couple of months ago, I had an eye-opening experience.
I was at a GraphQL conference,
where the audience consisted of front-end developers.

Now front-end developers are a new generation.
They did not exist back when RDF was conceived.

They are the people who make the cool things that we see.
They’re developers who want build fun stuff
and have fun while doing so.
Several of them are actually proud of the fact
that they are not “decent programmers”,
but that they nonetheless make things work nicely.

If we want to see more Linked Data apps,
they are our target audience.

We need to make working with Linked Data fun.
We need to focus on the developer experience.

Over the past couple of months, I spent quite some time
in the context of the Solid ecosystem
thinking about how to make Linked Data programming fun.

A key decision there is that I aim to
enable them to program with Linked Data
without having to program with RDF.
So in the context of this thread,
“easier RDF” to me means “Linked Data”.


The main question is to see what tooling *they* are using
and how to tap into their ecosystems.
And guess what, they are not using Java
like the majority of our stacks :-)
They’re using JavaScript, TypeScript, React, etc.

That’s an important reason why the RDF/JS community
in the past couple of years has been working
to bring things to the browser.
Check out our work at https://github.com/rdfjs



Some of my recent work involves bringing Linked Data to React.
See it here: https://github.com/solid/react-components

And especially look at the source code of an example application:
https://github.com/solid/profile-viewer-react/blob/master/src/App.js

There’s Linked Data, WebID, FOAF, etc. happening there,
but developers are not exposed to RDF.
Compare this to the RDF-oriented alternate version:
https://github.com/solid/profile-viewer-tutorial/blob/master/index.html

https://github.com/solid/profile-viewer-tutorial/blob/master/scripts/main.js

Both codebases are the same app, but totally different developer experiences.


Crucial for such a good developer experience
are also the right query languages.
As much as I use SPARQL myself, it’s just too complex.

Here’s a JavaScript-based language for path queries,
which reduce things such as “the user’s list of friends”
to three words (user.friends.label) instead of a SPARQL query:
– https://github.com/solid/query-ldflex

– https://solid.github.io/ldflex-playground/


Here’s our some work for GraphQL over Linked Data
by just providing a JSON-LD context to GraphQL queries:
– http://query.linkeddatafragments.org/

– https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/


These are all things front-end developers recognize,
and they get enthusiastic when they see this.
They think Linked Data is fun. (RDF not so much.)


By enabling front-end developers to build Linked Data applications,
we massively extend our reach.
I’ve had many conversations with front-end devs the past couple of months,
and understanding their mindset is key to getting traction.

Best,

Ruben

PS A blog post on the Linked Data developer experience
with the elements from this mail is in progress.

Received on Thursday, 22 November 2018 08:53:51 UTC