Closed dougwhitehead closed 11 years ago
If I understand correctly, you'd like something like
That would be great. It would allow me, as the guy setting up the SPARQL endpoint, to suggest queries. This would help
As you and I know, SPARQL is not harder to figure out than SQL. But still SPARQL adoption rate has been a challenge.
BTW, If you allow the user to add their own, where would you store these queries? On the user's local machine or on the server?
Doug
On Fri, Feb 8, 2013 at 6:10 AM, LaurensRietveld notifications@github.comwrote:
If I understand correctly, you'd like something like
- a properties files where you can define the default values (this case for the endpoint, but possibly also for other options such as the query parameters)
A sample set of queries, configurable from a properties file. I'd go for the ability to save/edit queries as well (about the same functionality, just not from a properties file)
— Reply to this email directly or view it on GitHubhttps://github.com/LaurensRietveld/yasgui/issues/66#issuecomment-13286016.
Currently everything is stored using html5 storage (i.e. locally, but persistent unless you clear your cookies) if available. Doing it properly on the server would require user management functionality. I'm still not sure whether I want to go down that road, as it makes the app a bit more bloated.
That makes sense. I haven't used HTML 5 storage. Cool.
Doug
On Fri, Feb 8, 2013 at 8:33 AM, LaurensRietveld notifications@github.comwrote:
Currently everything is stored using html5 storage (i.e. locally, but persistent unless you clear your cookies) if available. Doing it properly on the server would require user management functionality. I'm still not sure whether I want to go down that road, as it makes the app a bit more bloated.
— Reply to this email directly or view it on GitHubhttps://github.com/LaurensRietveld/yasgui/issues/66#issuecomment-13290289.
To enhance this further, how about a means of naming and retrieving the query in question? For example: http://myserver.com/yasgui/findhospitals Would bring up yasgui with the "findhospitals" query already loaded.
This would allow me to write documentation with links to queries that retrieve information. Once again, this is all in the name of making it easier for novice developers to get started using SPARQL
I like the idea, but am hesitant to link it to this feature. I was thinking about a more generic approach, where you'd pass the query and endpoint as url parameters, e.g. http://myserver.com/yasgui/?query=SELECT.....&endpoint=http://.... Does this fit your usecase as well?
I suppose it would work. Its a little unwieldy for a URL. And very similar to the sorts of invocations that you use for the actual sparql endpoint. I was hoping to have instructional comments in the query itself. I suppose thats possible also with urlencoding of newline and such. Here is an example query
####################################### #
#
# ####################################### # PREFIX gd: http://reference.data.gov/def/govdata/ PREFIX hoco: http://healthdata.gov/def/hospital-compare/ PREFIX dcterms: http://purl.org/dc/terms/ PREFIX comp: http://healthdata.gov/def/compare/ PREFIX hosp: http://healthdata.gov/def/hospital/ PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema# SELECT DISTINCT ?date ?place
?measure ?metric ?percentage ?footnote ?denominator ?ratio ?medianTime
?admissions ?rsmrLow ?rsmrHigh ?rsrrLow ?rsrrHigh ?stateCount
?nationalCount ?medianPayment ?msdrg ?footnoteId WHERE {
#
# { http://reference.data.gov/id/country/US hoco:recordset ?rs. GRAPH ?g { ?rs hoco:record ?record. } ?place hoco:recordset ?rs. } UNION { http://healthdata.gov/id/hospital/490101 hoco:recordset ?rs. GRAPH ?g { ?rs hoco:record ?record. } ?place hoco:recordset ?rs. } UNION { GRAPH ?g { http://healthdata.gov/id/hospital/490101 hoco:recordset ?record. } ?place hoco:recordset ?record. } ?g dcterms:issued ?date. #
#
?record comp:measure http://healthdata.gov/id/measure/51. http://healthdata.gov/id/measure/51 rdfs:comment ?measure. ?record comp:metric http://healthdata.gov/id/metric/19. http://healthdata.gov/id/metric/19 rdfs:comment ?metric. #
# OPTIONAL { ?record gd:percentage ?percentage. } OPTIONAL { ?record hoco:stateCount ?stateCount. } OPTIONAL { ?record hoco:ratio ?ratio. } OPTIONAL { ?record hoco:medianTime ?medianTime. } OPTIONAL { ?record hoco:nationalCount ?nationalCount. } OPTIONAL { ?record hoco:msdrg ?msdrg. } OPTIONAL { ?record comp:footnote ?footnoteId. ?footnoteId rdfs:comment ?footnote. } OPTIONAL { ?record gd:denominator ?denominator. } OPTIONAL { ?record hoco:admissions ?admissions. } OPTIONAL { ?record hoco:rsmrLow ?rsmrLow. } OPTIONAL { ?record hoco:rsmrHigh ?rsmrHigh. } OPTIONAL { ?record hoco:rsrrLow ?rsrrLow. } OPTIONAL { ?record hoco:rsrrHigh ?rsrrHigh. } OPTIONAL { ?record hoco:stateCount ?stateCount. } OPTIONAL { ?record hoco:medianPayment ?medianPayment. } } ORDER BY ?date
The hash on a new line (comments in SPARQL) messed up the formatting of the comment above.
all this would be doable using an long url encoded string right? Problem is, we have 2 scenarios: 1) the example queries are stored in a properties file on a server, and others are possibly added in html5 local storage by the user 2) no example queries are used, no properties file on a server is filled with these queries (e.g. the regular yasgui installation), and the user may have stored his own queries in local storage. Other users may have stored different queries in their local storage as well (possibly using the same ID)
I've got the feeling your approach would work more or less for the first scenario, but not for the second. I'd prefer picking a solution which works for situations where the query isnt saved/stored.
Is your reluctance towards url encoding the query the hassle of encoding it, or is it the long string? If it's the first thing, I was thinking about making a
icon, which would generate the yasgui url containing the url encoded string, for easy sharing
Icon thingy might be nice. But I don't have a problem url encoding a string.
You ask about my reluctance. Maybe I have spent such energy on my Queries of Interest, that I name them.
With your urlencoding pre-populating the query, I can implement what I want anyway using urlrewriterfilter.
I've added the option to configure YASGUI for local installations. See these wiki pages: https://github.com/LaurensRietveld/yasgui/wiki/Deploying-Yasgui https://github.com/LaurensRietveld/yasgui/wiki/Config
I've also added the 'Queries of interest' as a separate issue on github (see #73), as well as the option of using url arguments to load queries and endpoints #68 )
Let me know if this all works out for you
While it is not required, its great to deploy a client right beside a SPARQL endpoint. Changing the default endpoint in yasgui source is easy enough. But it would be nice to have a pallet of sample Queries of Interest that are specific to my endpoint.