Currently haswbstatement is case-insensitive. We may have a keyword for case-sensitive value query.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Closing out low/est priority tasks over 6 months old with no activity within last 6 months in order to clean out the backlog of tickets we will not be addressing in the near term. Please feel free to reopen if you think a ticket is important, but bare in mind that given current priorities and resourcing, it is unlikely for the Search team to pick up these tasks for the indefinite future. We hope that the requested changes have either been addressed by or made irrelevant by work the team has done or is doing -- e.g. upgrading Elasticsearch to a newer version will solve various ES-related problems -- or will be subsumed by future work in a more generalized way.
Comment Actions
Re-opening tasks and removing from team workboard per IRC feedback given yesterday and discussion with MPham.
Comment Actions
Some identifiers (such as P356) are case-insensitive, but others (such as P3083) are case-sensitive. We have no control over it, since those are identifiers in external sources. As a result, when I'm searching for haswbstatement:"P3083=* b Cen" I'm getting:
- https://www.wikidata.org/wiki/Q2072696#P3083 (* b Cen)
- https://www.wikidata.org/wiki/Q4836952#P3083 (* B Cen)
and there is no way I can limit my search to the first result only.
Either case-sensitivity parameter in search or corresponding property text in results (so I can filter second entity by myself) would work for me.
Comment Actions
Can you make a separate API request for the corresponding property text based off the q number you receive?
Comment Actions
Yes, I can. But it will add an unwanted layer of complexity in my code as well as impose additional burden on wikidata servers via additional wbgetentities request.