Hello,
We are experiencing a few issues with queries to Wikidata returning “500: Internal server error”, stating the query is invalid. If we alter the queries just a little bit, leaving out the last letter of the name we are looking for (for example ‘Brosame’ instead of ‘Brosamer’), the query works, giving us a correct result.
However, as of monday morning, the few queries that were consistetly giving us an error, are now working as expected. Both the ‘complete’ query and the altered version give us the same result, albeit with a higher score on the complete query.
Would somebody know where the problems came from, and what was changed to fix them? I am glad the issues are gone, I would just like to understand what was going wrong in the first place and whether we have a way to mitigate this on our end in the future.
The query URL’s are:
Kind regards,
I’m afraid I can’t help here although if I try those query URLs in a browser then I see an error which suggests there is some problem from the Wikidata reconciliation service end.
Is it possible that it’s the length of the query that’s causing the issue?
@ostephens thank you for taking a look. If I compare the two queries, one is 241 characters long and the other 275. However, if I remove the last letter of the names in either query, they go from an error to a result. So it doesn't seem to me that the length of the query plays a role here.
an error which suggests there is some problem from the Wikidata reconciliation service end
Is there somewhere else where I could post about this specific issue? I thought this was the recommended board.
Also, today the queries return results once again. This was not the case as recently as tuesday. Very strange.
This forum is definitely a good place to start but where the issue lies with an external service (which seems to be case here - at least that's what it looks like to me) then you may need to follow up with that service.
There are people in this forum who are very familiar with the Wikidata reconciliation service, but to report an issue directly to the people who maintain this service, this can be done at Issues · NFDI4Culture / TA1 data enrichment / OpenRefine Wikibase · GitLab
Apologies that I've not been able to help in this case.
Is there somewhere else where I could post about this specific issue? I thought this was the recommended board.
In addition to the reconciliation service bug tracker that Owen pointed to, you might also consider reporting the problem directly to Wikidata since the information returned with the errors from the reconciliation service indicate that the underlying Wikidata API is actually returning 500s as well.
The first Wikidata API query is returning a status of 500 with
Request ID: b9d84ee0-3fe8-4029-8688-648732abbd04
Allowed memory size of 698351616 bytes exhausted (tried to allocate 4198400 bytes)
While the second Wikidata API query is returning 500 with no additional details.
Tom
@ostephens @tfmorris I appreciate the follow-up. I will report this on gitlab to continue my investigation over there, and I’ll be sure to update this thread with any new information.
This Wikibase reconciliation service is currently essentially unmaintained: Paul (who made the fork) has left TIB and so he is not working on this anymore. I am not working on it either at the moment.
There are chances we can improve on this situation in the coming months (but I can't announce anything yet).
In the meantime, because I have permissions on this fork, let me see if I can enable other people to contribute.
Also this query: wikidata.reconci.link/ru/api?queries={"q0":{"query":"Аксаков, Александр Петрович","properties":[{"pid":"P570@year","v":1917}]}}
fails with
{
"arguments": {
"lang": "ru",
"queries": "{\"q0\":{\"query\":\"Аксаков, Александр Петрович\",\"properties\":[{\"pid\":\"P570@year\",\"v\":1917}]}}"
},
"details": "'precision'",
"message": "invalid query",
"status": "error"
}
But this query: wikidata.reconci.link/ru/api?queries={"q0":{"query":"Аксаков, Александр Петрович","properties":[{"pid":"P569@year","v":1850}]}}
works fine:
{
"q0": {
"result": [
{
"description": "schrijver",
"features": [
{
"id": "P569@year",
"value": 100
},
{
"id": "all_labels",
"value": 100
}
],
"id": "Q29358538",
"match": true,
"name": "Аксаков, Александр Петрович",
"score": 100,
"type": [
{
"id": "Q5",
"name": "человек"
}
]
}
]
}
}
Maybe that's because Aleksandr Aksakov Q29358538 has "no value" in its date of death property, while date of birth is specified as usual.
That's another interesting bug, thanks for the analysis! That could be reported in the issue tracker: