Re: simplerdf & Towards the future RDF library

Dear all,
thanks a lot for the nice welcome and thanks @elf for sharing this.

I have two points to make about this conversation about my personal experience that summarize the conversation

1) Interoperability. We can work on the same library, but what we should do - really -  is to work on the same spec.
This is why I joined the development of rdf-ext, they defined an interface that all of the packages me and others wrote adopt it.
Now, I shall not be forced to use RDF-Ext forever, in fact, I can just pick and mix different packages and they would still interoperate

2) Modularization. We can work on one unique library, but we would gain much more by decomposing all of our libraries (what we are doing with rdf-ext) and follow (1). To give an example, SimpleRDF accepts a graph, as long as you pass a graph that supports RDF-Interfaces, you can use any library. The interesting thing of RDF-Ext is that when it will be completely modularized, then its scheleton would be incredibly thin for everyone to personalize it.

In other words, a joint effort for one final library would be incredibly great,
but - whether the final library may or may not exist - by having simple contained modules supporting the same interface will win in either cases.

I am happy to join and discuss further the directions towards a future RDF library.
The SimpleRDF is a proof of concept I would like you to experiment and introduce new ideas,
maybe this simplicity will be preferred by the users not in our field over a traditional library using RDF-Interfaces/Ext

Nicola Greco
- Keep on rocking the free web

> On Sep 12, 2015, at 9:43 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> Hi bergi,
> 
>> The changes required in RDF-Ext to implement everything I described in
>> my last mail. Some of that is already done.
> 
> I understand, but perhaps we should ask questions like the ones below.
> If we build a joint RDF library X, would that library…
> a) …integrate parsers and processors from other libraries,
>    or have all these implemented in one place?
>    (For instance, RDF-Ext uses N3.js for parsing now,
>     with the associated performance penalty.)
> b) …use RDF Interfaces as internal format,
>    or is that too expensive? (And if not, which one?)
> c) …use promises or streams, or (asynchronous) iterators?
> 
> Note that this is by no means a criticism on RDF-Ext or any other library.
> It's a question of: how do we build such a thing together?
> RDF-Ext is starting to do a good job on integration,
> but perhaps if we al contribute to a single library,
> the end result is even more powerful than an integration?
> 
> For instance, I'd be more than happy to move N3.js development
> to a larger library so all those conversions are not necessary anymore.
> But before I do this, I want/need to be involved in architectural decisions
> of that larger library, because I'm well aware of how they affect parsers.
> 
> My personal opinion is that we need more something like a Jena for JavaScript:
> one (modular) library for which things are being implemented.
> One the one hand, the separated development is non-sustainable;
> e.g., I'm more than happy that many people use my N3.js.
> One the other hand, we should not loose individual progress:
> e.g., I don't think it makes sense to redo all the N3.js development.
> So therefore I'd rather agree on one core library design,
> in which I integrate N3.js once and for all (dropping the current custom format)
> and from that point on only develop for that library, together with you all.
> 
>> I'm open for discussions,
>> but I expect most discussions in modules around RDF-Ext.
> 
> Well yes, but if RDF-Ext is to become the joint RDF library X,
> shouldn't we all have a close look at the design decision of RDF-Ext?
> Especially if RDF-Ext is going to provide core constructs like triples and quads,
> we need to make sure that everyone agrees.
> 
> (Not attempting to hijack RDF-Ext here of course;
> but our goals as a group might or might not align with it yet.)
> 
>> A wiki page would be good, but we have to make sure information is not
>> redundant, out of sync or even lost because of the different services we
>> are using.
> 
> +1
> 
> At the moment, it seems that even this list is confused about initiatives
> (I certainly am). We can only imagine how hard it is for outsiders.
> 
> Best,
> 
> Ruben