Smalyshev added a comment.
Not exactly Quarry, but see https://commons.wikimedia.org/wiki/User:TabulistBot - this should be similar to Listeria and generate persistent reusable tabular data.
@Lucas_Werkmeister_WMDE I agree there are some downsides to this model, but I think it's the easiest and
Lucas_Werkmeister_WMDE added a comment.
I don’t think that’s a good fit. Query results aren’t necessarily notable for Commons, nor are they necessarily pure data (e. g. labels and descriptions, image links, or constructed result columns – the most extreme example would be the “cocktail recipes”
Smalyshev added a comment.
IIRC https://www.mediawiki.org/wiki/Extension:Graph can work with tabular data. WDQS GUI can't export into graphs though, except for Graph Builder, so there's some improvement possible there.TASK DETAILhttps://phabricator.wikimedia.org/T104762EMAIL
Daniel_Mietchen added a comment.
In T104762#3806240, @Smalyshev wrote:
Tabular data on Commons should be a good place for it, not? Do we need yet another place/way to store tabular data?
That seems like a good option indeed. In that case, we'd need a way to pull the data back into the WDQS for
Smalyshev added a comment.
We want to be able to save query results and share them
Tabular data on Commons should be a good place for it, not? Do we need yet another place/way to store tabular data?TASK DETAILhttps://phabricator.wikimedia.org/T104762EMAIL
Lucas_Werkmeister_WMDE added a comment.
In T104762#2635939, @Multichill wrote:
With the current SPARQL setup it's easy to share queries either by full url or by short url. I think we can close this one.
I disagree: one important part of this task, saving results, isn’t served at all by this. We
jcrespo added a comment.
@Base, your questions are very interesting, and you seem to have really nice suggestions, but I would suggest a mailing list, wiki talk page (or if it was a bug/feature request, doing them on a separate ticket), as the preferred way to communicate.
This ticket is probably
Base added a comment.
Do I get it right that now a query cannot be longer than URL length limit? How much exactly is that number? I wonder if there were cases of people needing to run longer queries. Is this investigable somehow?TASK DETAILhttps://phabricator.wikimedia.org/T104762EMAIL
Multichill added a comment.
With the current SPARQL setup it's easy to share queries either by full url or by short url. I think we can close this one.TASK DETAILhttps://phabricator.wikimedia.org/T104762EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Base added a comment.
In https://phabricator.wikimedia.org/T104762#2270182, @Multichill wrote:
> In https://phabricator.wikimedia.org/T104762#2269919, @Base wrote:
>
> > A stupid question by a person with bad SQL (progressed from almost zero
mostly thanks to quarry) and almost no
Multichill added a comment.
In https://phabricator.wikimedia.org/T104762#2269919, @Base wrote:
> A stupid question by a person with bad SQL (progressed from almost zero
mostly thanks to quarry) and almost no SPARQL knowledge: would it be possible
to have part of a request being made in
Base added a comment.
A stupid question by a person with bad SQL (progressed from almost zero
mostly thanks to quarry) and almost no SPARQL knowledge: would it be possible
to have part of a request being made in SQL and part in SPARQL and have it all
output as one table? (Like select a list
Multichill added a comment.
In https://phabricator.wikimedia.org/T104762#1426466, @yuvipanda wrote:
I think it'll be simpler to just have Quarry handle SPARQL as well.
Fine with me too :-)
TASK DETAIL
https://phabricator.wikimedia.org/T104762
EMAIL PREFERENCES
yuvipanda added a subscriber: yuvipanda.
yuvipanda added a comment.
I think it'll be simpler to just have Quarry handle SPARQL as well.
TASK DETAIL
https://phabricator.wikimedia.org/T104762
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: yuvipanda
14 matches
Mail list logo
