Re: simplerdf & Towards the future RDF library

Hi,

Am 12.09.2015 um 17:00 schrieb Nicola Greco:
>> On Sep 12, 2015, at 10:38 AM, Ruben Verborgh
>> <ruben.verborgh@ugent.be> wrote:
>>> 1) Interoperability. We can work on the same library, but what we
>>> should do - really -  is to work on the same spec.
>> 
>> +1 for this, regardless of other outcomes. But this would require
>> us to talk about such a spec together. For instance: callbacks /
>> promises / streams / (async) iterators? And several other
>> questions, notably: how to model a triple?
> 
> Agreed

I'm open to discuss any piece of RDF-Ext/RDF-Interfaces. But my focus is
and was always to have low barriers for people that are new to RDF. A
little performance drawback is OK for me, if the API is at the end much
more readable.

>>> 2) Modularization. We can work on one unique library
>> 
>> Yes, but is such an approach proven to work?
>> 
>>> but we would gain much more by decomposing all of our libraries
>> 
>> I think we should make a much closer pro/con analysis to be able to
>> conclude that. It depends on the definition of "gain" as well.
>> Performance we won't gain, I'd imagine.
> 
> I am not sure what you mean by performance gain - requiring a module
> is the same thing as requiring a file where you write your functions.
> Think of Express.js for example, 0.3 -> 0.4 was all about decomposing
> it in multiple modules.
> 
> Actually, a key reason I had when I asked bergos to decompose his
> library was to improve performance in serving my static js file. In
> fact, to serve my web app in javascript I can just browserify what I
> need, instead of browserifying the whole (previous) library.

Just two examples which show that the modular approach works:

https://www.npmjs.com/package/passport
https://www.npmjs.com/package/turf

Many modules are maintained by the same people and I expect/hope that
will be also the case for RDF-Ext, but that approach is also open for
other modules.

>>> 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.
>> 
>> +1
>> 
>> But still… some centralized coordination would not be bad. It's not
>> clear to me now who decides on RDF-Ext, and how we could influence
>> that. Can we discuss somewhere about the essentials? How do we get
>> involved with the RDF-Ext core?
> 
> RDF-Ext was a library by @bergos & friends and I later suggested them
> to start an organization about the project and that’s how I joined -
> we actually don’t know each other in real life. I think this shows
> that the library is really new that it’s there for new ideas and
> directions. I am sure @bergos will be open as well.
> 
> To directly answer your question, we opened this repo
> (https://github.com/rdf-ext/discussions) to discuss ideas, so, what
> happened so far, was an organic growth of the library - and that’s
> what we expected to happen.

Some weeks ago it was only me and my Zazuko colleagues who had access to
the RDF-Ext repository. Nicola told me his ideas and many of that was
already in my mind, we agreed on the rest of his ideas and he did
already some great work on the project in his own repositories. That was
the start of the RDF-Ext github organization. We have not written down
any rules yet, but to become a member of the organization I expect
contributions. But I think that's the usual open source project guide
line, we are following.

> However, I think that we - as the rdfjs group - can also bring this
> and the RDF-Ext spec conversation in an appropriate place as
> suggested by others

I invite everybody to write down proposals and ideas to:

https://github.com/rdf-ext/discussions


bergi

Received on Saturday, 12 September 2015 21:41:36 UTC