Re: simplerdf & Towards the future RDF library

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

Received on Saturday, 12 September 2015 13:44:34 UTC