openlink/rdf-editor

The OpenLink Structured Data Editor enables editing of RDF documents (in TURTLE notation) stored in a variety of HTTP accessible documents. Actual document access requires the target document is served from a system that supports at least one of the following open standards: Linked Data Platform (LDP), WebDAV, SPARQL 1.1 Update, or the SPARQL Graph Protocol.

rdf-editor's Issues

Add the ability to reference locally hosted ontologies

Referring locally hosted ontologies to be used as linked vocabularies would be a nice feature.

These referenced ontologies/linked vocabularies could be hosted either on file system or in a local virtuoso endpoint (exposed through SPARQL).

PS. You could refer to this discussion

Invalid behaviour on HTTP 400 error responses

When using a SPARQL endpoint for document location, RDF Editor pops up an authentication dialog in case of HTTP 400 error response from the endpoint. For example, RDF4J server responds with HTTP 400 error in case of SPARQL syntax errors in the request (with the body containing the explanation/error details).

I suspect that RDF Editor might show the authentication dialog on any 4xx errors, while it should do so only in case of 401. Perhaps, when encountering other 4xx errors, it should show the error pop-up (as it already does), but with the response body contents, to give users some idea why the error occurred.

Quick Build Instructions unclear after bower install

I am on Windows 7 (soon Windows 10) OS and find the installation instructions unclear after the bower install. I suggest adding additional detail there for where the commands should be executed, for the poor souls like me stuck with Windows.

Different endpoints for SPARQL SELECT/UPDATE

Some SPARQL servers use different endpoints for reading and updating data. For example, I'm using RDF4J server that expects SPARQL SELECT queries at http://localhost:8080/rdf4j-server/repositories/test and SPARQL Update requests at http://localhost:8080/rdf4j-server/repositories/test/update (old legacy convention, I know...)

Unfortunately, RDF editor allows only one endpoint for "Storage Locations". What about an option to have "split endpoints", when adding a new storage location?

Option to "forget" previous named graphs

When adding a named graph on the SPARQL Endpoint (used for saving documents), users are allowed to provide invalid graph URIs. When saving documents to that location, the invalid URI persists throughout all SPARQL requests, which result in error responses from the SPARQL server.

Currently there is no option to get rid of those errors (except "hard-reloading" RDF Editor). I suggest either (a) validating graph URIs at graph URI creation time and/or (b) allowing users to clear/delete/edit the graph URIs to "fix" that.