Change Details

I recently created a Commons template, "[[https://commons.wikimedia.org/wiki/Template:Category_contains | Category contains]]", to store a SPARQL-based specification for the content of the category, and present a WDQS query to see what is on Wikidata that appears to match. (See eg [[https://commons.wikimedia.org/wiki/Category:Grade_I_listed_buildings_in_Bedfordshire | example use on a category]]; and [[https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump&type=revision&diff=233482243&oldid=233458821 | post to Commons Village Pump]] to introduce and motivate it). I hope the template gets taken up widely, because I think it could be very useful for the Structured Data for Commons project to be able to analyse at scale the kind of combinations that typically-used categories represent; and to present people with an idea of what (Wikidata + Structured Topic Data) might currently be able to achieve; how close (or not) it might be able to get to the contents of present-day categories; and what sort of properties currently need better data coverage on Wikidata if WD+SD is to get nearer to what categories can currently show for a particular combination and refinement of topics. But it made me realise that there are a couple of tweaks to the WDQS output that could really make a big difference in the usability of the onscreen output for this kind of purpose, ie people comparing available content on Commons with the output of queries: - It would be good if the values of property P:373 ("Commons category") could be presented as links rather than plain text. (The same also goes for the values of external identifiers). Yes, it's easy enough to CONCAT the domain and cast the string to a URL, but it makes the output look a lot messier and harder to read. It would be nice if internally the column of values were being retrieved as (URL + text)-valued objects, and could then be presented as such. - It's an issue that the image thumbnails link directly to the full size images (often huge). I accept this may be exactly what one wants for batch queries, but usually for interactive work one doesn't want that huge image. Often what one wants to get to, especially for investigatory work on the image, or to see how it compares with other possible images that could have been chosen to be the P18 value instead, would be the Commons file page, which one can't get back to from the full big image. A really good compromise perhaps might be if it were possible for the thumbnail to link to the MediaViewer for the image. A user could then either click onwards to the full-size image, or instead follow the link from MV to the Commons file page instead. And a real bonus would be if the links for the rest of the image results from the query could be sent as the rest of the "carousel" of images that MV displays, so that one could click through an MV slideshow of them if one wanted. - Finally, it would be good if there could be a way to switch between different views when a query has been run in "kiosk" mode -- ie via the `embed.html` page. At the moment, with a query that could potentially be usefully looked at as a table, or a gallery, or a map, it's quite hard to explain in type to someone how to get out of "kiosk" mode, go to the query screen, re-run the query, find the display button, then select the alternative display. It would be very nice to have on-screen buttons to simply toggle between the (available, relevant) different display modes, similar to how the very nice "layers" button appears currently in the map view. Perhaps another "#" directive at the top of the query could be used to signal which views to offer in kiosk mode, if the data turned out to be there to support them. I hope this doesn't sound as if I am carping, because I am totally blown away by what you guys have achieved with WDQS and its amazing range of outputs in the last few months. But this would be the last 2% that would just be the icing on the cake.

I recently created a Commons template, "[[https://commons.wikimedia.org/wiki/Template:Category_contains | Category contains]]", to store a SPARQL-based specification for the content of the category, and present a WDQS query to see what is on Wikidata that appears to match. (See eg [[https://commons.wikimedia.org/wiki/Category:Grade_I_listed_buildings_in_Bedfordshire | example use on a category]]; and [[https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump&type=revision&diff=233482243&oldid=233458821 | post to Commons Village Pump]] to introduce and motivate it). I hope the template gets taken up widely, because I think it could be very useful for the Structured Data for Commons project to be able to analyse at scale the kind of combinations that typically-used categories represent; and to present people with an idea of what (Wikidata + Structured Topic Data) might currently be able to achieve; how close (or not) it might be able to get to the contents of present-day categories; and what sort of properties currently need better data coverage on Wikidata if WD+SD is to get nearer to what categories can currently show for a particular combination and refinement of topics. But it made me realise that there are a couple of tweaks to the WDQS output that could really make a big difference in the usability of the onscreen output for this kind of purpose, ie people comparing available content on Commons with the output of queries: - It would be good if the values of property P:373 ("Commons category") could be presented as links rather than plain text. (The same also goes for the values of external identifiers). Yes, it's easy enough to CONCAT the domain and cast the string to a URL, but it makes the output look a lot messier and harder to read. It would be nice if internally the column of values were being retrieved as (URL + text)-valued objects, and could then be presented as such. - It's an issue that the image thumbnails link directly to the full size images (often huge). I accept this may be exactly what one wants for batch queries, but usually for interactive work one doesn't want that huge image. Often what one wants to get to, especially for investigatory work on the image, or to see how it compares with other possible images that could have been chosen to be the P18 value instead, would be the Commons file page, which one can't get back to from the full big image. A really good compromise perhaps might be if it were possible for the thumbnail to link to the MediaViewer for the image. A user could then either click onwards to the full-size image, or instead follow the link from MV to the Commons file page instead. And a real bonus would be if the links for the rest of the image results from the query could be sent as the rest of the "carousel" of images that MV displays, so that one could click through an MV slideshow of them if one wanted. I hope this doesn't sound as if I am carping, because I am totally blown away by what you guys have achieved with WDQS and its amazing range of outputs in the last few months. But this would be the last 2% that would just be the icing on the cake.

I recently created a Commons template, "[[https://commons.wikimedia.org/wiki/Template:Category_contains | Category contains]]", to store a SPARQL-based specification for the content of the category, and present a WDQS query to see what is on Wikidata that appears to match. (See eg [[https://commons.wikimedia.org/wiki/Category:Grade_I_listed_buildings_in_Bedfordshire | example use on a category]]; and [[https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump&type=revision&diff=233482243&oldid=233458821 | post to Commons Village Pump]] to introduce and motivate it). I hope the template gets taken up widely, because I think it could be very useful for the Structured Data for Commons project to be able to analyse at scale the kind of combinations that typically-used categories represent; and to present people with an idea of what (Wikidata + Structured Topic Data) might currently be able to achieve; how close (or not) it might be able to get to the contents of present-day categories; and what sort of properties currently need better data coverage on Wikidata if WD+SD is to get nearer to what categories can currently show for a particular combination and refinement of topics. But it made me realise that there are a couple of tweaks to the WDQS output that could really make a big difference in the usability of the onscreen output for this kind of purpose, ie people comparing available content on Commons with the output of queries: - It would be good if the values of property P:373 ("Commons category") could be presented as links rather than plain text. (The same also goes for the values of external identifiers). Yes, it's easy enough to CONCAT the domain and cast the string to a URL, but it makes the output look a lot messier and harder to read. It would be nice if internally the column of values were being retrieved as (URL + text)-valued objects, and could then be presented as such. - It's an issue that the image thumbnails link directly to the full size images (often huge). I accept this may be exactly what one wants for batch queries, but usually for interactive work one doesn't want that huge image. Often what one wants to get to, especially for investigatory work on the image, or to see how it compares with other possible images that could have been chosen to be the P18 value instead, would be the Commons file page, which one can't get back to from the full big image. A really good compromise perhaps might be if it were possible for the thumbnail to link to the MediaViewer for the image. A user could then either click onwards to the full-size image, or instead follow the link from MV to the Commons file page instead. And a real bonus would be if the links for the rest of the image results from the query could be sent as the rest of the "carousel" of images that MV displays, so that one could click through an MV slideshow of them if one wanted. - Finally, it would be good if there could be a way to switch between different views when a query has been run in "kiosk" mode -- ie via the `embed.html` page. At the moment, with a query that could potentially be usefully looked at as a table, or a gallery, or a map, it's quite hard to explain in type to someone how to get out of "kiosk" mode, go to the query screen, re-run the query, find the display button, then select the alternative display. It would be very nice to have on-screen buttons to simply toggle between the (available, relevant) different display modes, similar to how the very nice "layers" button appears currently in the map view. Perhaps another "#" directive at the top of the query could be used to signal which views to offer in kiosk mode, if the data turned out to be there to support them. I hope this doesn't sound as if I am carping, because I am totally blown away by what you guys have achieved with WDQS and its amazing range of outputs in the last few months. But this would be the last 2% that would just be the icing on the cake.