Jul 24 2020
See https://tinyurl.com/y26mtate for an example of how this is currently done. Given that items returned will virtually always be images (or at least things that can be represented as images) i guess it makes sense that every query always returns images and maybe uses the ImageGrid view as the default as well.
May 26 2020
@CBogen cool, thanks for the update. Really looking forward to be able to test something!
May 25 2020
May 24 2020
@Ramsey-WMF you might want to take a look at the prototype again, i've improved it quite a bit with a couple of new things:
May 18 2020
+1. Machine learning is a good usecase, but there are many others:
May 12 2020
Yeah, i noticed that. Seems like a small but interesting step!
May 10 2020
May 8 2020
May 7 2020
I don't see the same things that @Dominicbm sees, so this might have been fixed by the rollback?
May 4 2020
+1. SPARQL is definitely not for the 'average' user, fortunately we don't have many average users on our projects. Also note that a SPARQL endpoint can easily serve as the fundament of tools that are more user-friendly, for example my own VizQuery uses the Wikidata SPARQL service. To adapt that to a future stable SDoC / Commons endpoint would literally be a one-line code change. It already works on the old beta service (if that would still work).
Apr 6 2020
Mar 16 2020
+1. It's pretty hard to stay excited about SDoC when there's no proper way to view the hard work that is being done with editing all images, *especially* when there's no way to take Wikidata items into the same query. What's the point of tagging all the reproductions of the Mona Lisa with a 'depicts' statement if there's no way to do a query on them? Or having a completely separate, other way of doing that?
Dec 16 2019
@Gehel, thanks for your response!
@Jarekt afaik this is only a proof of concept. However, the data does seem to be updated (previously it only had the data from april or so). I don't know who is currently maintaining the beta, but maybe @Lea_Lacroix_WMDE or @Lydia_Pintscher knows.
Dec 9 2019
Another domain is fine for me. About the privacy/security implications: now people are using alternatives like bit.ly and tinyurl.com over which we have zero control in terms of privacy implications. So i guess anything we can create/control ourselves would be better.
Dec 8 2019
Nov 23 2019
Nov 22 2019
The tool mentioned by @Spinster above is done and working over here:
Well, the tool is done and working:
I've also added support for PagePile ids now. Also in the hash by the way:
A fixed a couple of problems and all the example lists posted in this issue should now work!
Nov 18 2019
@Spinster, i don't think so. There's no unique identifier, and the data itself is pretty meagre compared to the Rijksmonumenten database. Let's not waste more effort in doing something with this dataset.
Nov 11 2019
Nov 5 2019
Should we still do this? See my previous comment. I doubt this dataset is very useful.
Oct 28 2019
Aug 29 2019
May 29 2019
@Ecritures misschien wel interessant, maar ik zou er eerst even in moeten duiken.
@Ecritures ik heb hier wel aan gewerkt, maar ik kan me niet meer zo heel goed herinneren of het iets heeft opgeleverd. Wat mij betreft mag het van het bord.
May 17 2019
It would also be really nice if this could export to either GeoJSON or TopoJSON, because it makes it a lot easier to integrate query results in visualisation tools. For example, Vega-lite maps.
Nov 7 2018
@valhallasw thanks for trying out a couple of things, and indeed confirming that using the location won't work. I was pretty confused by the HNO / HNE columns as well, unfortunately there doesn't seem to be any kind of description of what those fields actually mean.
@valhallasw that could be an interesting option, but would it also work if there are many monuments that are close to each other, like in the centre of Amsterdam?
When looking closer at this dataset i doubt it's going to be very useful. There's a couple of reasons for that:
Nov 6 2018
@1Veertje: i downloaded your SQL files and converted them to a CSV dump (see attachment). However, i think maybe something went wrong because i don't see many improvements. Many of the streetnames seem to be truncated because of a VARCHAR limit, e.g. rijnr 8895 now has 'Burgemeester van Dobben de Bru' instead of 'Burgemeester van Dobben de Bruijnstraat'. i've also included a Jupyter Notebook with the zip file, maybe you can see for yourself if i missed something.
Oct 27 2018
Here's a video of the current (very basic) prototype: https://www.youtube.com/watch?v=e59qKhin1Mg&feature=youtu.be
Oct 26 2018
Not quite sure how useful this is. Matching might be quite difficult because the archives are referring to many different things (people, organisations). I guess manually matching this might be faster than trying to scrape it and trying to automatically match archives / wikidata items.
@S9a8m let me know if you need some assistance with scraping, i can help.
Oct 16 2018
Oct 10 2018
Sep 24 2018
@Aklapper Yes, most definitely. Thanks!
Jun 29 2018
@Pigsonthewing sure thing. This should now work.
Jun 28 2018
Here's something i wrote: https://www.wikidata.org/wiki/User:Husky/ifff-viewer-link.js
Jun 25 2018
I've removed the tool from the Toolforge servers, and removed all the references from other places in my tools. I don't think it really worked anyway. For anyone who's interested: the code for this project is still available as an old commit on my Github: https://github.com/hay/wiki-tools/tree/b760c5607e5aa7b05d83ef02e7d03259619e9ab8/public_html/streetwiki.
May 20 2018
@Lea_Lacroix_WMDE what i basically want is an option to use the wbgetentities method with an option to query by label in the same way you can query ids or titles. I was working on matching a set of street names to WD items, i could of course do an individual query for each street using wbsearchentities, but then i can only query one item at a time. So basically i could imagine something like:
May 18 2018
Okay, so @Krinkle helped me with getting the old SVN dump into my Github repo, and i hacked the code really ugly and got it working again on the most recent version of WordPress.
@Aklapper the code is actually still on my Github repo:
May 3 2018
May 1 2018
@matej_suchanek i've tried that, but unfortunately searching by label using SPARQL is far too slow. Queries time out or take forever.
@matej_suchanek both of these options are not useful, i want to query by label, not by ID.
Apr 30 2018
Feb 7 2018
Note that the current spec is available here:
Feb 15 2017
thanks @Dereckson for pointing me towards this discussion, didn't even know there was this discussion on upgrading the tool directory.
Dec 30 2015
Hey @Deskana, i'm wondering why you reassigned this task to 'lowest priority'. Thanks!
Jul 9 2015
@Mholloway: cool! Thanks!
Jul 7 2015
The screenshots look really promising! Any chance this will also make the iOS release?