Re: report of the October meeting

On Thu, Nov 5, 2015 at 9:33 AM, Ruben Verborgh <ruben.verborgh@ugent.be>
wrote:

> Hi Melvin,
>
> > I suppose we all have our favourite js rdf libraries and favourite
> features.
>
> Yes, but the problem is that none of the RDF libraries have a complete
> feature set,
> and that each library has their own way of representing triples.
> We want to unify the way of representing triples,
> so all libraries can talk to each other more easily;
> This makes it easy to combine the features we need.
>
> > OTOH we are a small group with divided resources.
>
> And we're trying to unify those resources.
>
> > Would it be fair to say that most of the RDF JS libs are in the category
> "hobby project", no direspect meant by the term.
>
+1

>
> Some of them are, but not all of them.
> If I can speak for my own libraries, they are production-level code.
> BUT they represent triples in their own way, so conversions are necessary..
>
I agree that the code quality of these projects is sometimes
production-level. Hobby project might be the wrong term, but most of these
projects are either written in a context of academic projects with a
limited runtime, or in the spare time of some developers. Projects from
both scenarios often do not have longevity: Academic code often stalls in
development after the project finishes, and I can only name a few projects
that are supported by one or two developers and have been going strong for
many years.

gr Laurens


> > I'd suggest that maybe the MIT library (rdflib.js) has could be
> something more given that there is a team behind it, tim is behind it, and
> MIT is hiring new people to help with support and development:
>
> While I'm sure it's a good effort, some of the code is nowhere far as
> production-level as other libraries.
> For instance, the parser is a conversion from a Python library; I expect
> performance to be bad.
> I on't know to what extent it is spec-compatible. It is not streaming.
>
> > Sure, it would be nice if there were a few more features added (frankly,
> I dont need them just yet) and perhaps standardize some of the naming, api
> and data structures.
>
> Exactly, standardizing is what we want to do.
> That way, everybody can extend any JavaScript library for RDF, and they
> just work together.
>
> > But how about we use rdflib.js as a practical BASE library, along with,
> say bergi's for Rdf Intefaces, rdfstore for sparql, n3.js for n3 etc.
>
> …and to do that, we need a uniform representation format, which is what we
> strive to build.
> Otherwise, we'll spend too much time and effort on conversions on every
> step.
>
> Furthermore, I don't think that rdflib.js is fit as a base.
> I mean, if we indeed have to pull in RDF Interfaces, rdfstore, and N3.js,
> we already have a functionally complete library and don't need rdflib.js.
>
>
> What I would propose instead is that:
> – we write a spec for a low-level representation format and API for
> JavaScript RDF libraries
> – existing libraries are converted to adhere to this spec
> Once libraries are compatible
> – developers can combine the libraries they want
> – we can build one core library with many features, supported by many devs
>
> I myself look forward to stop independent N3.js development,
> but maintain it as part of a larger library that others contribute to.
>
> Best,
>
> Ruben
>