Re: simplerdf & Towards the future RDF library

Hi everyone,

It's Saturday evening and I just saw Rubens tweets so after going back
and forth with him a bit on Twitter I have to do a quick braindump
before I jump into the technical discussion. This is going to be long
and it will explain my  skepticism and positions in later emails so you
can safely ignore this message if you just care about the technical points.

First, some of my RDF and JS history: Shortly after I discovered RDF and
Linked Data I got convinced that for a breakthrough we have to get much
better on frontend or it will probably stay in a niche forever. After
realizing that it became pretty clear that the most important work in
that regard has to be done in the browser and JavaScript. I got even
more convinced by that once I discovered node.js and started using it.
Yes this is a few years back, node.js was still new and SPARQL 1.1 not
finished yet.

Next I had a look what options I had. The only one which looked useful
back then was Antonios rdfstore. I used it quite a lot but ran into more
and more problems which I reported. Unfortunately Antonio didn't had
much time and didn't really want to give access to the repo away so lots
of stuff just died there and bugs didn't get fixed for months, even with
hints on what has to be done.

While using rdfstore I noticed that it's based on [RDF
interfaces](http://www.w3.org/TR/rdf-interfaces/) which was back then
not finished as a spec but not declared dead by W3C either. I was very
grateful that we had this spec as we at least had some documentation
(even if many argue that a spec is not documentation) and an idea of how
it could be done. I managed a few times to talk to webr3 but it became
also clear that he won't be the one pushing this further either.

Now it's a good moment to mention that I'm more the one with ideas and
the ability to convince people to pay me and my company to solve some
problems they have than coding all that stuff on my own. I would love to
be the one but I'm really not a great programmer and even less a fast
one. So I couldn't do it myself.

Around this time I also found webr3's
[JS3](https://github.com/webr3/js3) which I found brilliant because it
was super simple. Problem was that it was totally standalone and not
really useful in that form.

Around that time me and some friends started to envision another thing
called [Uduvudu](https://github.com/uduvudu/uduvudu) which I still think
will be crucial for RDF on the UI level but more about that later. For
Uduvudu I needed someone which does all the crazy JS-RDF bootstrapping I
had in mind.

Then, by great chance, a colleague of mine found
[@bergos](https://github.com/bergos). Thomas sent me some source he was
working on and I was ecstatic as I found someone which implemented at
least half of the stuff I had in my mind. Later this became
[rdf-ext](https://github.com/rdf-ext/rdf-ext) and we published that on
Github. It was still based on RDF interfaces but he started to extend it
the way I had it in mind myself.

The goal of rdf-ext from my perspective is quite simple:

- just do the stuff no one else did before as we are not big enough for
starting from scratch
- integrate parsers for all important RDF serializations, including RDF/XML
- provide a store object abstraction which provides an API which I can
use on whatever backend I decide to use. Ideally I just change the
creation of this store object and all the stuff I did magically works on
another backend
- document that stuff so others start using it and contribute (yes,
that's the one where we definitely didn't succeed yet)

I'm super grateful that people like Ruben started doing some of the
really hard work that needed to be done. Like doing an N3/Turtle parser
which actually works on whatever you throw at it. And later he basically
fulfilled my old dream of creating a clean SPARQL parser as well in JS.
I totally see where Ruben wants to go with LD Fragments but that's where
I start to have my issues. My current use cases are not really connected
to what Ruben does (LD Fragments perspective I mean) and with Thomas I
found someone which not just got me but also joined the company we
founded in October last year.

This brings me to another thing: It's great that some people on this
list can spend a lot of time bootstrapping important bits and pieces
payed as research. For me and Thomas (partially, he does a hell lot of
work in sparetime) this is not the case. We can work on the stuff when
we can pay our bills and this means it solves a problem a customer has.
So that might explain why starting from scratch was simply not possible
for us. This is by the way the reason why Uduvudu is still in its
initial phase, I simply couldn't organize enough money yet to pay the
needed work to make it a real product. Last but not least, I have an
ego. I'm proud on the ideas I have and when we invest time, I want to be
able to say "we did that for a big part". That's how Open Source
business models work.

Before Nicola joined rdf-ext was released under an umbrella from our
company Zazuko. I was very happy that he started to contribute and ask
questions so later he asked if we could move the repository to rdfjs
group instead. I discussed that with my colleagues at Zazuko and we
decided to do an rdf-ext group instead as we would like to be known as
the sponsors of this work as well and this is easier to do if this is
not the rdfjs group. One argument I gave in was that this group is not
really active anyway and we didn't had any contributions from that side.
So that's funny as around two weeks later Ruben now starts this
discussion :-) And by the way, I was initiating the rdfjs group back
then for the reason that I wanted to have these kind of discussions.
Unfortunately it didn't really spark when we started it.

What Nicola now showed with his proposal is great, unlike JS3 this might
work for me. I think what Ruben actually asks is do we really want to
have something like RDF Interfaces as a foundation. He mentioned
promises as well and it totally makes sense to think of that today. You
can see that there are [issues for
that](https://github.com/rdf-ext/rdf-ext/issues/44) in rdf-ext, we
clearly have to head into that direction and away from callback hell.

I personally don't think that RDF Interfaces is that important anymore.
I rarely used more than a few functions in there and in the end it's a
total PITA when you want to do serious work. That's one of the reasons
why Thomas came up with clownface for example:

var cf = rdf.cf.Store(new rdf.promise.Store(new rdf.LdpStore()));

cf.node('https://nicola.databox.me/profile/card#me')
  .then(function (cf) {

console.log(cf.out('http://www.w3.org/ns/pim/space#preferencesFile').literal().shift());
  });

So my point is if we really going to do some new thing we need to have a
clear understanding of what we aim to solve, agree on how we do that
work and companies like Zazuko/us need to have a benefit from this.
Otherwise investing time does not make sense. Also, I don't want to end
in the situation I was with rdfstore where nothing happened and we had
node modules on npm full of bugs which no one could fix.

That's it for the moment. Sorry for being verbose, had to write this
down for myself as well :)

regards

Adrian







-- 
Adrian Gschwend
@ netlabs.org

ktk [a t] netlabs.org
-------
Open Source Project
http://www.netlabs.org