7

I am using github to share a set of SPARQL queries:

http://www.boisvert.me.uk/opendata/sparql_aq+.html?file=specific%20sensor.txt

Currently the simple work allows end-users to access queries stored on the github repository, but ultimately I want to allow them to also modify the queries, as with a pastebin, and make use of the repository to better manage the shared system. Ideally I would want end-users who may not be very tech-savvy, to be able to make minor changes to queries to an open, linked data endpoint: so to keep the technology barrier low.

My problem is this: how best to structure the github project and exploit the API to make the most of the available information? I can think of different points:

  • Currently the project (https://github.com/boisvert/unshaql) holds client code and example queries. Does it make a difference to create an independent project (separate from the web client code) for SPARQL queries?
  • I would use directories within the project to classify/tag queries, and file names to title them. Are there better alternatives? It strikes me that a hierarchical structure is not a good fit to tags.
  • When end-users save, a simpler (and cruder) option is to allow them to push their file into just one branch, which holds the examples. A better engineered one would be to allow them to use their github credentials to fork the set of SPARQL queries and edit theirs, but with unaware users, how do I avoid creating a mess?
1
  • 2
    It seems to me that since your pain point is github being too high a barrier for your end users, you are definitely going to have to create a new platform for yourself. sparqlbin.net is available :) Commented Oct 30, 2015 at 17:23

2 Answers 2

3

You could allow users to upload/email .txt files containing queries, or upload URLs (e.g. pastebin, gist). Then your local code would read these .txt queries and add them to the repository (also standarized the query, validate the query, format the query, etc).

1
  • Yes (and gist: YES!) - I think a public place like gist is preferable, because users can access their code in flexible ways. But as you say, a simulaneous way to manage the gists (validate etc) is needed.
    – boisvert
    Commented Nov 2, 2015 at 8:17
2

You should check out grlc

grlc, the git repository linked data API constructor, automatically builds Web APIs using SPARQL queries stored in git repositories.

Basically you use an github repository which stores all your queries. Based on it, a swagger doc is generated what is easy to browse through (even with tags and description)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.