search

Triply-Dev / YASGUI.legacy

Yet another SPARQL GUI
http://legacy.yasgui.org
MIT License
44 stars 8 forks source link

Add queryUrl parameter #225

Closed jneubert closed 9 years ago

jneubert commented 10 years ago

The "permanent link" feature which allows to communicate queries as a YASGUI URL with a set of parameters is a really great tool for sharing.

An additional "queryUrl" parameter could specify some location on the web from where to load a query, instead of obtaining it literally via the "query" parameter.

This would allow for specifying queries saved elsewhere, e.g. https://raw.github.com/jneubert/skos-history/master/sparql/added_concepts.rq.

I'd see several use cases for this enhancement, such as:

LaurensRietveld commented 10 years ago

I like the collaborative aspect of this idea.

I got some questions though:

  1. How would users load the query in YASGUI? Would the follow a link provided by a third party? (with the queryUrl as argument). Or is a change required to the YASGUI interface?
  2. Changing the queries which are saved elsewhere happens 'outside of YASGUI'. I guess this approach has both advantages as well as disadvantages: Advantages: location of where query is store is under your control. i.e., no dependency on YASGUI being up. Additionally, this method offers a better flexibility, such as using the query in other tools Disadvantages: -changing- the query is not possible via YASGUI, only -loading- the query

What would you think about a bookmark functionality turned into 'query catalogue'? I.e. allowing users to publish queries to a YASGUI query catalogue, for other users to try and change.

jneubert commented 10 years ago

ad 1. I don't suggest changing the user interface, but just providing an additional parameter for URLs provided by third party.

ad 2. I'd think of such a parameter as an additional feature, which allows for addressing third party (public) repositories. This would be independent of what is possible within yasgui.

I'm currently working on a project, which includes experiments with RDF data structures, and SPARQL queries which can be run on such queries (https://github.com/jneubert/skos-history), as well as scripts which generate triples stores with these datastructures. Outside the project, these queries do not make a lot of sense. Plus, changing structures require a changes in queries, and I want to keep all code in sync within one repository. It would be very welcome, however, to be able to expose the queries not just as downloadable code, but additionally as links into an environment, where others can play with it. Permanent changes to the queries in the repository would be outside of the responibility of yasgui (and could be made, e.g., by pull requests or commit rights).

A public query catalogue could be nice too, paricularly as starting point for new users. But to make and keep it useful would require a lot of work (verifying if the queries work on just one single repository, or should work more generally - and explaining that they don't do actually, as disucssed in #224). When I look at my personal sparql/bin directory, I'd have to figure out the context, scope and function of the saved queries quite hard ... - and that would be much harder for queries saved and published by others. So I imagine that the organization of published queries could be a project in itself, or could be left to the persons who publish then in their "user space".

What you said about integrating yasgui into toolchains is also appealing. An ecosystem of SPARQL-related tools would be a good thing. I see some of this already, e.g. in VisualRDF or the jsonld playground. Users may combine such tools in way we cannot know, and yasgui could play the role of an interactive interface for experimenting with queries. So, if queries could be saved and published within yasgui, and referenced by URI (using the same mechanism as for queries saved elsewhere), the discussed features could complement each other nicely.

jneubert commented 10 years ago

As an example for an intended use of a queryUrl parameter you may look at https://github.com/jneubert/skos-history/tree/master/sparql, where the README contains links to yasgui queries (which currently have to be rebuild every time the query is improved - sigh ...).

LaurensRietveld commented 10 years ago

jup, point taken. That's a nice usecase. I'll make sure to incorporate this feature

LaurensRietveld commented 9 years ago

Hi Joachim,I'll try to include this in YASQE: https://github.com/YASGUI/YASQE/issues/23