Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
1) The maintainers point-blank refuse to let it allow URLs of more than 2000 characters. ( https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
2) The short URL could be for anything on any wiki site -- the EMEW site can't be sure that it corresponds to a SPARQL query
3) The short URL needs to be adjusted, to turn it from a WDQS url that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
James,
I work with Wikidata in an academic library setting, and frequently use the WDQS in my work and to demonstrate the power and value of Wikidata to colleagues. I found myself copying and pasting a whole query into the notes of a presentation slide yesterday rather than trying to paste in the URL from WDQS.
I would use identifiers for queries in my daily work, and I think this is a fantastic idea. A place to save and share queries, like Quarry, would be useful for sharing SPARQL/WDQS expertise as well.
I don't have privacy concerns about my WDQS queries, but I could see that objection happening. Maybe saving and adding identifiers to queries could be an opt-in kind of thing?
Best,
Crystal Clements University of Washington Libraries
-----Original Message----- From: Wikidata wikidata-bounces@lists.wikimedia.org On Behalf Of James Heald Sent: Thursday, February 18, 2021 5:33 AM To: wikidata@lists.wikimedia.org Subject: [Wikidata] Identifiers for WDQS queries
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
1) The maintainers point-blank refuse to let it allow URLs of more than 2000 characters. ( https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
2) The short URL could be for anything on any wiki site -- the EMEW site can't be sure that it corresponds to a SPARQL query
3) The short URL needs to be adjusted, to turn it from a WDQS url that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Another option would be to store the query on your Wikidata home page using the {{SPARQL}} template and then sending a link to the page section for it. Here’s an example:
https://www.wikidata.org/wiki/Template:SPARQL#Examples
Jeff
From: Wikidata wikidata-bounces@lists.wikimedia.org on behalf of Crystal E. Clements cec23@uw.edu Date: Thursday, February 18, 2021 at 12:02 PM To: Discussion list for the Wikidata project wikidata@lists.wikimedia.org Subject: [External] Re: [Wikidata] Identifiers for WDQS queries James,
I work with Wikidata in an academic library setting, and frequently use the WDQS in my work and to demonstrate the power and value of Wikidata to colleagues. I found myself copying and pasting a whole query into the notes of a presentation slide yesterday rather than trying to paste in the URL from WDQS.
I would use identifiers for queries in my daily work, and I think this is a fantastic idea. A place to save and share queries, like Quarry, would be useful for sharing SPARQL/WDQS expertise as well.
I don't have privacy concerns about my WDQS queries, but I could see that objection happening. Maybe saving and adding identifiers to queries could be an opt-in kind of thing?
Best,
Crystal Clements University of Washington Libraries
-----Original Message----- From: Wikidata wikidata-bounces@lists.wikimedia.org On Behalf Of James Heald Sent: Thursday, February 18, 2021 5:33 AM To: wikidata@lists.wikimedia.org Subject: [Wikidata] Identifiers for WDQS queries
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
1) The maintainers point-blank refuse to let it allow URLs of more than 2000 characters. ( https://phabricator.wikimedia.org/T220703https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
2) The short URL could be for anything on any wiki site -- the EMEW site can't be sure that it corresponds to a SPARQL query
3) The short URL needs to be adjusted, to turn it from a WDQS url that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/https://quarry.wmflabs.org) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidatahttps://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidatahttps://lists.wikimedia.org/mailman/listinfo/wikidata
Thank you, Jeff! I was unaware of this template.
From: Wikidata wikidata-bounces@lists.wikimedia.org On Behalf Of Young,Jeff (OR) Sent: Thursday, February 18, 2021 9:38 AM To: Discussion list for the Wikidata project wikidata@lists.wikimedia.org Subject: Re: [Wikidata] Identifiers for WDQS queries
Another option would be to store the query on your Wikidata home page using the {{SPARQL}} template and then sending a link to the page section for it. Here's an example:
https://www.wikidata.org/wiki/Template:SPARQL#Examples
Jeff
From: Wikidata <wikidata-bounces@lists.wikimedia.orgmailto:wikidata-bounces@lists.wikimedia.org> on behalf of Crystal E. Clements <cec23@uw.edumailto:cec23@uw.edu> Date: Thursday, February 18, 2021 at 12:02 PM To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.orgmailto:wikidata@lists.wikimedia.org> Subject: [External] Re: [Wikidata] Identifiers for WDQS queries James,
I work with Wikidata in an academic library setting, and frequently use the WDQS in my work and to demonstrate the power and value of Wikidata to colleagues. I found myself copying and pasting a whole query into the notes of a presentation slide yesterday rather than trying to paste in the URL from WDQS.
I would use identifiers for queries in my daily work, and I think this is a fantastic idea. A place to save and share queries, like Quarry, would be useful for sharing SPARQL/WDQS expertise as well.
I don't have privacy concerns about my WDQS queries, but I could see that objection happening. Maybe saving and adding identifiers to queries could be an opt-in kind of thing?
Best,
Crystal Clements University of Washington Libraries
-----Original Message----- From: Wikidata <wikidata-bounces@lists.wikimedia.orgmailto:wikidata-bounces@lists.wikimedia.org> On Behalf Of James Heald Sent: Thursday, February 18, 2021 5:33 AM To: wikidata@lists.wikimedia.orgmailto:wikidata@lists.wikimedia.org Subject: [Wikidata] Identifiers for WDQS queries
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
1) The maintainers point-blank refuse to let it allow URLs of more than 2000 characters. ( https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
2) The short URL could be for anything on any wiki site -- the EMEW site can't be sure that it corresponds to a SPARQL query
3) The short URL needs to be adjusted, to turn it from a WDQS url that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/https://quarry.wmflabs.org) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.orgmailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.orgmailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
There is also {{query page}} https://www.wikidata.org/wiki/Template:Query_page, which is useful if you want to reuse the query elsewhere on Wikidata.
Cheers, Lucas
On 18.02.21 18:52, Crystal E. Clements wrote:
Thank you, Jeff! I was unaware of this template.
*From:* Wikidata wikidata-bounces@lists.wikimedia.org *On Behalf Of *Young,Jeff (OR) *Sent:* Thursday, February 18, 2021 9:38 AM *To:* Discussion list for the Wikidata project wikidata@lists.wikimedia.org *Subject:* Re: [Wikidata] Identifiers for WDQS queries
Another option would be to store the query on your Wikidata home page using the {{SPARQL}} template and then sending a link to the page section for it. Here’s an example:
https://www.wikidata.org/wiki/Template:SPARQL#Examples https://www.wikidata.org/wiki/Template:SPARQL#Examples
Jeff
*From: *Wikidata <wikidata-bounces@lists.wikimedia.org mailto:wikidata-bounces@lists.wikimedia.org> on behalf of Crystal E. Clements <cec23@uw.edu mailto:cec23@uw.edu> *Date: *Thursday, February 18, 2021 at 12:02 PM *To: *Discussion list for the Wikidata project <wikidata@lists.wikimedia.org mailto:wikidata@lists.wikimedia.org> *Subject: *[External] Re: [Wikidata] Identifiers for WDQS queries
James,
I work with Wikidata in an academic library setting, and frequently use the WDQS in my work and to demonstrate the power and value of Wikidata to colleagues. I found myself copying and pasting a whole query into the notes of a presentation slide yesterday rather than trying to paste in the URL from WDQS.
I would use identifiers for queries in my daily work, and I think this is a fantastic idea. A place to save and share queries, like Quarry, would be useful for sharing SPARQL/WDQS expertise as well.
I don't have privacy concerns about my WDQS queries, but I could see that objection happening. Maybe saving and adding identifiers to queries could be an opt-in kind of thing?
Best,
Crystal Clements University of Washington Libraries
-----Original Message----- From: Wikidata <wikidata-bounces@lists.wikimedia.org mailto:wikidata-bounces@lists.wikimedia.org> On Behalf Of James Heald Sent: Thursday, February 18, 2021 5:33 AM To: wikidata@lists.wikimedia.org mailto:wikidata@lists.wikimedia.org Subject: [Wikidata] Identifiers for WDQS queries
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007 https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
- The maintainers point-blank refuse to let it allow URLs of more than
2000 characters. ( https://phabricator.wikimedia.org/T220703 https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
- The short URL could be for anything on any wiki site -- the EMEW
site can't be sure that it corresponds to a SPARQL query
- The short URL needs to be adjusted, to turn it from a WDQS url
that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/ https://quarry.wmflabs.org) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
Wikidata mailing list Wikidata@lists.wikimedia.org mailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org mailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 2/18/21 12:52 PM, Crystal E. Clements wrote:
Thank you, Jeff! I was unaware of this template.
Hi Crystal,
Given a text bubble generated by your app [1] comprising:
Name: Thames Course: OS Head_N: Oxford Notes: Probably most traffic downstream Length: 64768 Class: known_bulk
What about using Wikidata URIs as hyperlinks for relevant text. Basically doing the following:
<a href="{uri-of-thames}">Thames</a>
Net effect, the aesthetics of raw URIs don't interfere with the content of your text bubbles.
This pattern works with any kind of URI i.e., SPARQL Query Results Pages or actual Entity Names.
I hope that helps.
Links:
[1] https://viaeregiae.org/index.php/map/?layers=l9001l0007l0009&bounds=58.7...
Kingsley
*From:* Wikidata wikidata-bounces@lists.wikimedia.org *On Behalf Of *Young,Jeff (OR) *Sent:* Thursday, February 18, 2021 9:38 AM *To:* Discussion list for the Wikidata project wikidata@lists.wikimedia.org *Subject:* Re: [Wikidata] Identifiers for WDQS queries
Another option would be to store the query on your Wikidata home page using the {{SPARQL}} template and then sending a link to the page section for it. Here’s an example:
https://www.wikidata.org/wiki/Template:SPARQL#Examples https://www.wikidata.org/wiki/Template:SPARQL#Examples
Jeff
*From: *Wikidata <wikidata-bounces@lists.wikimedia.org mailto:wikidata-bounces@lists.wikimedia.org> on behalf of Crystal E. Clements <cec23@uw.edu mailto:cec23@uw.edu> *Date: *Thursday, February 18, 2021 at 12:02 PM *To: *Discussion list for the Wikidata project <wikidata@lists.wikimedia.org mailto:wikidata@lists.wikimedia.org> *Subject: *[External] Re: [Wikidata] Identifiers for WDQS queries
James,
I work with Wikidata in an academic library setting, and frequently use the WDQS in my work and to demonstrate the power and value of Wikidata to colleagues. I found myself copying and pasting a whole query into the notes of a presentation slide yesterday rather than trying to paste in the URL from WDQS.
I would use identifiers for queries in my daily work, and I think this is a fantastic idea. A place to save and share queries, like Quarry, would be useful for sharing SPARQL/WDQS expertise as well.
I don't have privacy concerns about my WDQS queries, but I could see that objection happening. Maybe saving and adding identifiers to queries could be an opt-in kind of thing?
Best,
Crystal Clements University of Washington Libraries
-----Original Message----- From: Wikidata <wikidata-bounces@lists.wikimedia.org mailto:wikidata-bounces@lists.wikimedia.org> On Behalf Of James Heald Sent: Thursday, February 18, 2021 5:33 AM To: wikidata@lists.wikimedia.org mailto:wikidata@lists.wikimedia.org Subject: [Wikidata] Identifiers for WDQS queries
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007 https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
- The maintainers point-blank refuse to let it allow URLs of more than
2000 characters. ( https://phabricator.wikimedia.org/T220703 https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
- The short URL could be for anything on any wiki site -- the EMEW
site can't be sure that it corresponds to a SPARQL query
- The short URL needs to be adjusted, to turn it from a WDQS url
that's a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/ https://quarry.wmflabs.org) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
Wikidata mailing list Wikidata@lists.wikimedia.org mailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org mailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
James Heald, 18/02/21 15:33:
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/) where users could save their queries, share them,
PetScan does at least part of this. I've used it sometimes to share queries.
I suppose it's not forbidden to create a Wikidata item about a query. A query is an intellectual work and you can probably (ab)use some properties to add the actual query either as string (might be a bit too long) or link.
Federico
Hoi, What is the point? The results of a query may be different every time. You want to refer to the state at a given time. So it may not be forbidden but it does not add value. Thanks, GerardM
On Fri, 19 Feb 2021 at 11:34, Federico Leva (Nemo) nemowiki@gmail.com wrote:
James Heald, 18/02/21 15:33:
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/) where users could save their queries, share them,
PetScan does at least part of this. I've used it sometimes to share queries.
I suppose it's not forbidden to create a Wikidata item about a query. A query is an intellectual work and you can probably (ab)use some properties to add the actual query either as string (might be a bit too long) or link.
Federico
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
James - I support this 1000%. An important idea, and namespaces for queries are very valuable and currently underdeveloped + underappreciated in many environments.
I would want the query-space to be editable, with a version history for a given query ID: the idea being to make it easy to create and refine a sharable view of knowledge. Which is what we do now when creating a new page, portal, entity, category...
To your last concern, which I share: -- I would not auto-assign these IDs, but have them easy to request; in the fashion of bit.ly -- on request you are offered a (not human-readable) ID for that query, and can ask for a specific short string instead.
From an API perspective,
-- I like the idea of a URL that refers to a query and allows one to access its query string / history / last update time / results -- Gerard: yes, as of the [current time] when it is viewed. That's often what I want. It would be somewhat useful to have a way to indicate "as of <timestamp>", and Memento offers a mechanism for this. But we don't use Memento even for web-citations; we just include a "retrieved on" date in the citation data. So: not a priority.
SJ
On Thu, Feb 18, 2021 at 8:34 AM James Heald jpm.heald@gmail.com wrote:
Dear wikidata list,
One of the key things we do as Wikidata people is go round the internet, hassling people to create nice identifiers for their things, with URIs and landing-pages that we can link to.
It brought me up quite short to realise that actually applies to *us* too -- there is an important thing of ours that haven't got a linkable identifier for, that it would be useful if there was a short linkable url for, and that is WDQS queries.
So here's the use-case:
[[User:PKM]] and I have been working with a new external project who want to build a "Gazetteer of Early Modern England and Wales" (EMEW) -- basically a historical GIS for 15th & 16th century England and Wales, able to plot things on this map: https://viaeregiae.org/index.php/map/?layers=l9001l0007
There's huge scope for collaboration with Wikidata, with deep linking both ways, as we both try to improve our coverage of C16-C17 England and Wales (expect WikiProject [[:d:WD:EMEW]] just as soon as we can get the pages made)
Something that we realise we want to be able to do, from the EMEW site, is for a user to be able to give it the URL for a WDQS sparql query, for the site to send that to WDQS, get back a file of EMEW ids, and show the results on the EMEW map.
Now of course that *can* be done with full WDQS query URLs. But they are horribly long and awkward.
What would be much nicer would be if each time WDQS ran a query it hadn't seen before, it generated a new short identifier, that the UI would display, and which could then be used to refer to the query.
So on the EMEW site, one would just put in the short identifier, that would send it to WDQS with some appropriate URL-start to show it was a request for data rather than for a link, back would come the results -- and all the user would have had to copy in was a short identifier.
Of course to some extent the URL-shortener does this, but there are some issues:
- The maintainers point-blank refuse to let it allow URLs of more than
2000 characters. ( https://phabricator.wikimedia.org/T220703 ) Gnarly WDQS queries can often be longer than this, sometimes a lot longer.
- The short URL could be for anything on any wiki site -- the EMEW site
can't be sure that it corresponds to a SPARQL query
- The short URL needs to be adjusted, to turn it from a WDQS url that's
a link to the query in the GUI into a WDQS url that's an external request for query results. This is not straightforward.
A short identifier for a WDQS query would get round all these things.
It also might be one step forwards towards creating a place like Quarry (https://quarry.wmflabs.org/) where users could save their queries, share them, document them, see other people's shared queries, and come back to them later. But that's another ticket (https://phabricator.wikimedia.org/T104762 open since July 2015).
All I am suggesting, first, is an identifier.
One objection that I thought of might be that if identifiers were automatically assigned, without having to actually request them, then people might be able to "spy" on what other queries people happened to be writing at any one time. I don't know how serious an objection this is - it doesn't seem to be a problem for Quarry - but could largely be avoided if the query-number was hashed to make the sequence less predictable.
(Or alternatively, query-numbers could just be issued on request).
Anyway, just putting this out here, for thoughts.
Best wishes to everybody,
James.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata