If this project is dead, what's the alternative? #86
Comments
|
Since rdfstore-js uses my N3.js parser, I created pull requests to incorporate the latest version of this library. Maintaining a library of my own, I have however no intention of working on rdf-store.js. My personal plans are as follows:
In general, while I applaud @antoniogarrote's efforts to make this feature-complete rdfstore-js library, the source code is not in optimal shape. It is my personal opinion that it's not the best way to continue; but no other library is as feature-complete as this one (but recent efforts, such as TriG, are missing). Depending on what features you need, I highly recommend N3.js for the browser. We build cool applications with it, including this one. |
|
On 2/26/15 4:48 PM, Ruben Verborgh wrote:
We have worked with rdf-store.js and to date, there's no other We will continue to use this effort. Naturally, any bug fixes or new Our soon too be released RDF Editor does make use of rdf-store.js, for Regards, Kingsley Idehen |
|
Might not be everyone's cup of tea, but I am currently using : https://github.com/linkeddata/rdflib.js It's an active project with 20 commits in the last month from 5 different authors (judge that as you will!) I would say it requires quite a bit of web literacy to dive into, as the documentation relatively light. But I've been very happy with the results so far. |
|
@melvincarvalho Thanks for the pointer - as I extract from open issues, there is no support for JSON-LD, and I don't see any named graph handling (I might have overlooked something), which I need, too. So there seems to be an arms race in terms of features, which rdflib.js will be winning in the long run, given developer activity, but if you need these (and maybe other) features right now, you're stuck with rdfstore-js. Having said that - does anyone think there is potential to join efforts with the people working on/with rdflib.js? @kidehen It's great to hear that such a strong player in the community as OpenLink is backing this project. Would you be willing to maintain a fork for as long as nobody merges pull requests into the main project? Having said that, @antoniogarrote as people seem to be actively working on the code, might you be interested in creating an organization for rdfstore-js and adding those actively developing so we get unstuck? @RubenVerborgh Thanks for that pointer, too - I'll look into it. However, as my server doesn't support RDF Fragments, I suppose it is probably not what I need (reading linked data, preferably in quads - TriG, n-quads or JSON-LD) and querying them in SPARQL - however, that last part may be achieved differently) |
|
@antoniogarrote first of all: thank you for rdfstore-js. @RubenVerborgh and thanks to you for N3.js. We actually use it in addition to rdfstore.js since our fork does not contain your patches. @fkleedorfer I certainly do not have the time to maintain a fork of rdfstore.js all by myself but I am very open to the idea of doing it collaboratively. A first step would be to create a merged branch from all our patches and test the result in our individual projects. |
|
@antoniogarrote has helped integrate rdfstore.js into banana-rdf but I think he is very busy, and so things have not moved very far. I have tried fixing a few bug, but without the lack of progress on this branch has slowed my enthusiasm. We may have to remove it from banana-rdf now. But if a project presents itself that continues where rdfstore.js left off, then this will give us a good reason to continue maintaining that code. |
|
On 2/27/15 3:44 AM, Sebastian Trueg wrote:
We have to ensure all our patches are available to both of these projects. All: I think we can collectively bring more attention to these important Regards, Kingsley Idehen |
|
On 2/27/15 2:58 AM, fkleedorfer wrote:
We should always collaborate, at every turn. We need to build an
We are happy to work with @antoniogarrote Regards, Kingsley Idehen |
|
Given that rdflib.js might be the better alternative in the long run, and not knowing how many of the feature requests that we care about we can actually implement, I'd say the safest way to proceed is to follow @trueg's suggestion and merge our fixes/extensions, and we'll see where we go from there. So if you agree we:
That should at least leave us with a more stable version of what there is already and maybe somehing like a community around it, just in case. I have already created an organization to save time, so if you agree, please post here if you'd like to be added to the organization. Also, if someone else wants to be the owner of the organization, please step up :) Who's in? |
|
On 2/27/15 12:34 PM, fkleedorfer wrote:
Okay. I'll leave Sebastian to deal with the rest of the matter, from our side. Regards, Kingsley Idehen |
|
Hi, sorry I'm late to this conversation. Thanks also from my side for all the effort from all participants put into this project. We used rdfstore.js in the beginning quite intensively for our projects, but eventually shifted because of the lack of progress a bit. I had some exchanges with @antoniogarrote ca. a year ago. My interpretation is that after finishing his PhD he wanted to restart rdfstore.js with lessons learned in a complete rewrite (https://github.com/antoniogarrote/rdfstore-js/tree/1x). It seems though that he can not invest as many time he would like. In general I have the impression he was never against involving other developers, that is one of the reasons he was ok two switch to the MIT license as we asked him back then (a894cd7). I support the idea of @fkleedorfer to have at least a store where the patches get merged in a regular basis and also to have versioning. We should assure in this that @antoniogarrote is mentioned always as seed developer. Also please add him as an owner of the organization? Further I am happy to become a commiter of the fork. (Though not sure if of any use .. (-, ) |
|
Hi all. Sorry for not having been able to answer before. Unfortunately I haven't had much time in the last months to dedicate to this project and my perception was that interest on it was very limited so I have been unable to make any progress with the project. Any changes you want to make with the project or the code are more than welcome. If you need me to change the license, create an organization or transfer ownership of the code, please, just tell me. I started a rewrite of the code on Christmas. It's in the '1x' branch. It cleans the code, add much needed support for tools like gulp and dependency management, test automation, etc. I's currently 60% complete. I would use it as the basis of any further development. Scope of the ptoject needs to be reduced and focused. Part of the complexity of the code base originates on its research project nature where multiple engines are tried that need to be removed. I'll try to follow the conversation to see if I can be of any help. |
|
On 2/28/15 2:28 AM, Antonio Garrote wrote:
Great to hear! As a community we really need to learn how to work
Okay, so we somehow need to figure out the base for the pending merge
From my vantage point, the goal should be to have a SPARQL 1.1 DBMS for
Regards, Kingsley Idehen |
|
My efforts on using this code has centered on the ability to persistently store a small graph locally while using the federation features. The most significant stumbling blocks in the existing code base for me has been the few missing components of SPARQL 1.1, and inability to query all named graphs by default (without UNION). Antonio Garrote's 1x branch, imho, has set up the right direction in parsing (though incomplete) and indicates a possible abstraction layer or API between the query-engine and any kind of store one may choose to use... which is a great point of experimentation and development. Antonio Garrote's rdfstore.js is a solid body of work and I think a good foundation for any revitalized effort... I would be very happy to see it continued. |
|
While I very much like the idea of using the cleaned up 1.x branch as a basis I fear that none of us have the time to finish the missing 40% of it. That is why I support the idea by @fkleedorfer to start with my branch and merge anything any of us might have in their branches. Then at least we have a working version to maintain. Thus, I propose this:
|
|
About 2: With a tool such as hub, it is easy to get the code from all pull requests and merge it. Redoing the pull requests might not be realistic. |
|
Very well, then I guess we need to gather the list of branches that we want to merge rather than re-do pull requests. |
|
As it was not mentioned yet, one of the more feature complete projects is probably RDF-Ext by @bergos which is using RDFStore for the SPARQL store at least but that will be replaced with @RubenVerborgh SPARQL parser one day. We basically add features as needed so pull requests are very welcome as well. Note that @bergos tries to focus on the parts no one else did. Turtle is done by Rubens parser, JSON-LD from the JSON-LD guys, SPARQL currently as mentioned from Antonio and there is a LDP implementation as well which Thomas implemented himself. It also provides Promise interfaces where appropriate. |
The inability to query all graphs is also the issue I have with rdfstore-js. Did you find a solution? Or does someone have a suggestion how this could be implemented in rdfstore-js? |
|
@trueg I'm in favor of your suggestion - When I find the time, I'll try your version, most probably my modest changes are part of yours (adapting the JSON-LD implementation to changes in the JSON-LD specification). If this is not the case, I'll make a pull request. |
|
@fkleedorfer I did not touch the JSON-LD code. So just point me to where those patches are and I will merge them. |
|
Hi all. You can use it as the basis for any future branch/fork. Some advice to follow development of this branch:
Since there seem to be still some interest on the project, I will try to continue development of the 1.x branch that addresses a lot of the problems of the 0.x branch and should make the code easier for new developers. Regards. |
|
Great work, @antoniogarrote. Good to see you back! |
|
thank you all for getting back and reviving this. re: tests - one suggestion would be to start putting a travis.yml file so that every pr starts getting tested. |
I have not coded a solution. I think the quickest and most definitive answer to the question as to how named graphs could be nested into a default graph, in the context of existing rdfstore-js code, would come from @antoniogarrote. If he could point to the best place to start, that would be ideal. From what I can tell, the ability to traverse the contents of named graphs by default would both be contained in the query-engine (pattern used to discover named graphs within the triplestore) and the lexicon (system tracking of named graphs). Ideally, provision for enhanced treatment of named graphs could be provided for in the design of the triple store, likely benefiting from a quad-store (system level graph partitioning), or even quint-store (enhanced access control), but minimally speaking, the system could treat a named graph as a blank node. I know I am oversimplifying this, and I have moments of clarity and then get lost in it. But I believe the traversing named graphs issues is another good reason for abstracting the query engine to enable a wider variety of persistent stores to be used and more features to be bolted on. |
|
I've published the first version of the rewrite: 0.9.2. The codeis alread merged in master. I have tried to add some of the suggestions in the thread like, adding the project to Travis. |
|
About the datasets for queries, this is a small summary of how the store works. I think the question is what should be the default behaviour: Any query to the store accepts two sets of graphs as arguments.
Provided the following insertion: The following scenarios can happen:
-output: []
-output: [t1]
-output: []
-output: []
-output: [t1] |
|
@antoniogarrote Thank you for taking this up again. It is very much appreciated. I am now trying to use the new version in my projects but I am running into some trouble: |
|
I now created a simple file to enforce the "rdfstore" namespace. The file contains only one line and is the new input for browserify:
Not sure if that makes much sense - I am new to browserify and all its friends. |
|
Hi everyone. I have created a gitter room to continue the conversation. You can join from the README of the project. I have a number of things almost ready, like the bower packaging, but things are going to slow a little bit for a few weeks since I'm looking for a new job. Hope to start working on new functionality and making all the official W3C tests pass soon. |
I suppose other rdfstore-js users are wondering about this as I am.
I'm working on a project that requires an RDF store in the browser, I chose rdfstore-js as it seemed superior to the other options I checked (and there weren't many). So, above all: Thanks @antoniogarrote for building this! It's great, and, of course, it has its problems and bugs, but the most important problem is: it's abandoned.
The text was updated successfully, but these errors were encountered: