@Majavah, i see. Thanks for linking to that!

Okay, it seems logical then not to provide PHP 8 until Debian Bullseye is deployed? PHP 7.4 is actively supported until end november this year, and getting security support until end november 2022. Debian Buster is EOL in August 2022, so i imagine somewhere within that timeframe PHP 8 and/or a new Debian version might be coming?

This tool is now live here: https://hay.toolforge.org/depictor/

Would really love to see this version available as well, many new features to write cleaner code, including named arguments and union types. See here for a full list.

Yeah, great! This simplifies the queries so much, without that awful hack of using the string concat method. Finding all images depicting Douglas Adams is now just:

Copying my comment from the duplicate task here about why this would be very useful (apart from machine learning):

In T253053#6736635, @JeanFred wrote:

Appears to be a duplicate of T230315: [XL] Create a way to see and add references to structured data on Commons (MediaInfo) statements ?

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.

@CBogen cool, thanks for the update. Really looking forward to be able to test something!

Note that i've been working on a tool called Structured Search that is pretty much a proof-of-concept of how a revamped Commons search interface would look like. Also see ticket T252251.

@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:

+1. Machine learning is a good usecase, but there are many others:

In T252251#6125812, @Ramsey-WMF wrote:

1. A while ago, we updated the suggested search dropdown to include an easier way to do haswbstatement:P180 searches. Try any search on Commons using the default search box and you'll see the "Files depicting..." section at the bottom of the suggestion list.

Yeah, i noticed that. Seems like a small but interesting step!

I don't see the same things that @Dominicbm sees, so this might have been fixed by the rollback?

In T221921#6103577, @Spinster wrote:

As for a SPARQL endpoint being challenging for many end users from an UX perspective - I would say: don't underestimate our end users and community.

+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).

In T207170#6033359, @Aklapper wrote:

@Jane023, @Husky: Did someone work on this? Asking as Wikistorm 2018 and 2019 are over and as there are no other project tags on this task. If this should still be open, please add an active project tag via the Add Action... → Change Project Tags dropdown. Thanks!

In T208026#6033353, @Aklapper wrote:

I'm blodly closing this task per last comment, as Wikistorm 2018 is over and as no other project tag is added to this task.

In T221921#5973902, @Jarekt wrote:

That would be great. I think the frustration is due to expectations management.

+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?

@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.

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.

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!

@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.

Hey, as a proof of concept, i've adapted my VizQuery tool to use the beta endpoint.

Should we still do this? See my previous comment. I doubt this dataset is very useful.

In T222089#5225239, @Krenair wrote:

wmflabs.org should probably be a whole separate ticket.

@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.

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.

@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:

@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.

And the current code (now a nagfree script is located here

Here's a video of the current (very basic) prototype: https://www.youtube.com/watch?v=e59qKhin1Mg&feature=youtu.be

Try this: https://meta.wikimedia.org/wiki/PetScan#Get_the_sitelinks_for_a_certain_project_from_a_SPARQL_query

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.

@Aklapper Yes, most definitely. Thanks!

@Pigsonthewing sure thing. This should now work.

Here's something i wrote: https://www.wikidata.org/wiki/User:Husky/ifff-viewer-link.js

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.

@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:

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.

In T187896#4213200, @Husky wrote:

@Aklapper the code is actually still on my Github repo:

https://github.com/hay/photocommons

But i'll attend the session anyway. Looks interesting!

@Aklapper the code is actually still on my Github repo:

@matej_suchanek i've tried that, but unfortunately searching by label using SPARQL is far too slow. Queries time out or take forever.