I am dubious about the solutions proposed.
A simple query builder *might* be able to generate some of the queries required, but what is required (eg to appropriately define and limit the broader set of items of interest, or to characterise the combinations that identify problematic entries within that set) will often go beyond what can be expected of a query-builder -- but the novice user may not realise that what they are looking for is beyond the capabilities of the wizard; and if all they know is the wizard, then that may give them no sense of where to go next.
The existing wizard is of course particularly limited; but I fear a more complex wizard would still hit the same problem.
I can see that building a wizard may seem an attractive technical challenge for a coder. But I suspect it is the wrong approach to put resources into, and that it would be more productive to help users learn SPARQL itself for simple queries, rather than to push them towards a wizard interface, which will ultimately still prove inadequate.
I was struck in the research that nobody identified our online tutorials and introductions to SPARQL as useful.
A better approach, I think, would be to put resources into our documentation; and in particular making our online tutorials more discoverable and more "solution orientated".
I think we should be pushing users much more clearly towards something like the SPARQL tutorial originally written by Lucas https://www.wikidata.org/wiki/Wikidata:SPARQL_tutorial as a resource to 'get' the basic idea of SPARQL
After that, a "How do I ... ?" approach I think is useful -- for instance, here's an old page, some of the queries could be revised or improved, there are gaps and omissions to be filled in, but IMO a well-signposted reference organised something along these lines (ie how do I write queries with data including this, with data including that, etc) would be useful: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries
There is also useful content at https://en.wikibooks.org/wiki/SPARQL which could be built on (and this might be a good location for an examples-led reference manual).
Even a re-organisation of existing example queries into groups dealing with particular techniques or aspects of the data would be useful, compared to the existing rather random "isn't this clever" arrangement.
I think Harmonia was expressing some similar thoughts to this at WikidataCon, based on her extensive experience of SPARQL coaching and training.
Best regards,
James.
On 06/04/2020 15:55, Léa Lacroix wrote:
Hello all,
Over the past months, we researched how people use queries and lists. We also wanted to find out what problems people meet when getting started with using queries and lists for maintenance. You can find the results of the research in this document https://commons.wikimedia.org/wiki/File:Queries_and_List_Generation_for_Maintenance_%E2%80%93_Research_Slides.pdf.
Our next step is to make some proposals on new features, based on the results of the research. We worked on two concepts https://www.wikidata.org/wiki/Wikidata:Improve_the_workflows_for_queries_and_lists: a simple query builder https://www.wikidata.org/wiki/Wikidata:Improve_the_workflows_for_queries_and_lists/Simple_query_Builder and an improved example queries dialog https://www.wikidata.org/wiki/Wikidata:Improve_the_workflows_for_queries_and_lists/Improved_example_dialog. Your feedback is very welcome on the related talk pages until April 21st.
Thanks,
-- Léa Lacroix Project Manager Community Communication for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de http://www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata