Wikidata:Contact the development team/Archive/2021/09
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Irish National Inventory of Architectural Heritage ID P4088
For some time now, in instances where this Property is used in a Wikidata item and you click on the external link to the NIAH map, you are no longer brought that records location/information within the map. Back in 2017 when the property was added, you would click on the number and the NIAH map would navigate directly to the object associated with that record number. An example is Q4852004. This might be an issue with the sites certification, as both Chrome and Firefox flag the site? Smirkybec (talk) 12:55, 7 September 2021 (UTC)
- @Smirkybec: Looks like the design/construction of the site has changed. Existing links - e.g. http://webgis.buildingsofireland.ie/HistoricEnvironment/?REG_NO=50120060 - no longer find the desired item. The current URL for the item is https://www.buildingsofireland.ie/buildings-search/building/50120060/67-fairview-strand-dublin-3-dublin - and all that crap at the end is required, is not on WD. In the short term, the formatter URL could be changed to this sort of format: https://www.buildingsofireland.ie/buildings-search/?query=50120060 which returns a search result of the sought item. Longer term, someone'll have to amend the NIAH values WD holds, or else shout nicely at NIAH to un-break their website. --Tagishsimon (talk) 13:22, 7 September 2021 (UTC)
- @Tagishsimon: that's not the page that link used to point to, it looks like the map URL changed, as this is the kind of page you would have landed one: https://maps.archaeology.ie/historicenvironment/?REG_NO=50120060 - so it looks like that's the problem? Smirkybec (talk) 14:15, 7 September 2021 (UTC)
- @Smirkybec: In which case there's hope. I've changed the formatter ID on the property (diff). iirc, it takes ~ a day to propagate, so we'll see. --Tagishsimon (talk) 14:22, 7 September 2021 (UTC)
- @Tagishsimon: oh wonderful - thank you! I think I'm one of the few people to ever click on them, should have reported it a long time ago :P Smirkybec (talk) 14:32, 7 September 2021 (UTC)
- @Smirkybec: Seems to have worked. --Tagishsimon (talk) 21:54, 8 September 2021 (UTC)
| I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Tagishsimon (talk) 21:54, 8 September 2021 (UTC) |
Wikidata SPARQL Query links no longer working/displaying correctly
Hi all!
I'm a relative newbie to Wikidata, but I'm part of graduate research workshop at Michigan State University devoted to the study of comics, education, and digital humanities. Apologies for the rough formatting on this, but as mentioned, I'm a little new, but I am also trying to be thorough.
Back in April 2021, my team and I hosted a workshop where participants created Wikidata visualizations using https://query.wikidata.org/. Each group generated a few visualizations, and we kept the output links.
This was our basic SPARQL Query Template:
- defaultView:Graph
#This is our primary Wikidata Graph Query for the event. These hashtags (#) can let us put in notes about our query service. #This query service calls up specific traits, then asks whether it has titles/labels/images/connections associated with the item.
SELECT ?item1 ?image ?item1Label ?item2 ?image2 ?item2Label ?edgeLabel WHERE {
#Values here indicate what our Wikidata entries are. These are what the Query is searching for. Each Q-Code corresponds to a specific Wikidata item with the designator (wd:) followed by the QID. #update Values 1 and 2 to replace Q####### with Wikidata Item Q-codes; these items should be the same in both lines
VALUES ?item1 {wd:Q1274252 wd:Q2027419 wd:Q7256325 wd:Q323066 wd:Q3297851 wd:Q3567110 wd:Q16948328 wd:Q1257188 wd:Q15221656 wd:Q3482431 wd:Q312086 wd:Q2924461 wd:Q1500596} VALUES ?item2 {wd:Q1274252 wd:Q2027419 wd:Q7256325 wd:Q323066 wd:Q3297851 wd:Q3567110 wd:Q16948328 wd:Q1257188 wd:Q15221656 wd:Q3482431 wd:Q312086 wd:Q2924461 wd:Q1500596} ?item1 ?prop ?item2. ?edge ?dummy ?prop ; rdf:type wikibase:Property
#if there is an image, the following optional queries extracts the image --if any-- and includes it, as seen in Spy vs. Spy.
OPTIONAL {?item1 wdt:P18 ?image} OPTIONAL {?item2 wdt:P18 ?image2} SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } }
Currently, those links no longer work, and even the above SPARQL query's stable output link redirects to a broken image. We don't know what caused the issue. Here's another example. The stable link was: https://w.wiki/3Dty When we click it open, it now redirects to this (screenshot included to help show what's happening on our end):
Anyone have any insights as to what might be causing the issue? For further evidence, check out our once-interactive Wikidata Visualization Gallery.
I can't tell what the issue
Thanks! Justin Wigard Michigan State University
- In short, it looks as if embedded queries - those with a URL pattern starting https://query.wikidata.org/embed.html#%0ASELECT ... - are not working. Example: the cats example query: https://w.wiki/42jW --Tagishsimon (talk) 23:00, 20 September 2021 (UTC)
- @Justin.wigard: Seems to be fixed now. --Tagishsimon (talk) 17:42, 21 September 2021 (UTC)
| I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Tagishsimon (talk) 17:42, 21 September 2021 (UTC) |