Wikidata:Report a technical problem/WDQS and Search

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

Report a problemHow to report a problemHelp with PhabricatorGet involvedWDQS and Search

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/05.

Start a new discussion

Working with long SPARQL queries

I need to send long sparql queries to Wikidata from a python program, the conventional method to query wikidata is to include the query in the url parameters, as the sparql is too long this results in an error. After reviewing some wikidata documentation about the subject, I've found that: SPARQL queries can be submitted directly to the SPARQL endpoint with a GET or POST request to https://query.wikidata.org/sparql. GET requests have the query specified in the URL, in the format https://query.wikidata.org/sparql?query=(SPARQL_query), e.g. https://query.wikidata.org/sparql?query=SELECT%20?dob%20WHERE%20{wd:Q42%20wdt:P569%20?dob.}. POST requests can alternatively accept the query in the body of the request, instead of the URL, which allows running larger queries without hitting URL length limits. (Note that the POST body must still include the query= prefix (that is, it should be query=(SPARQL_query) rather than just (SPARQL query)), and the SPARQL query must still be URL-escaped.) I've checked to run a really long sparql query in the UI of wikidata and found they also used post to run the query, nevertheless, when I run the query using a POST method including the query as part of the payload, I always receive 405 method not allowed, I've checked and I query the same URL than the UI: https://query.wikidata.org/sparql, but it works for the UI and doesn't work when I run it in python or postman. Any idea of what am I doing wrong? Javiersorucol1 (talk) 23:08, 7 May 2023 (UTC)

@Javiersorucol1: the POST payload must conform to the w:URL_encoding#The_application.2Fx-www-form-urlencoded_type spec, here is a working example using curl:

curl -XPOST --data-urlencode "query=select * { ?s ?p ?o } LIMIT 1" https://query.wikidata.org/sparql

DCausse (WMF) (talk) 10:00, 9 May 2023 (UTC)

query does not reflect current state (not even yesterday's state)

Tracked in Phabricator
Task T350348

see Query (query 1 for landform (Q271669)). It returns normally, but does not show current data. Mind the cluster NNE of Graz (e.g. Sauernkogel (Q21865369) - which I changed almost one day ago to have a located in the administrative territorial entity (P131) to be a municipality, which is the filter criteria). When I replace the landform (Q271669) by mountain (Q8502) (and do not change anything else): Query (query 2 for mountain (Q8502)), the cluster NNE of Graz is gone. any fix and help appreciated. My question is not about a workaround to make the query run, but to get an error message instead of incorrect data. best --Herzi Pinki (talk) 14:19, 11 September 2023 (UTC)

one remark. The query works from time to time and updates to a current state. So the situation described above may go, but the underlying problem remains. --Herzi Pinki (talk) 14:35, 11 September 2023 (UTC)

Thanks for reporting this problem, unfortunately it is not possible for the query service to know if it has the current state when running a query. In normal conditions the query service servers should reflect all edits with a minimal delay (less than 10minutes). It might happen for a numerous number of reasons that query service server you are hitting might return stale or inconsistent results. In order for us to investigate we need more precise information and a way to reproduce the issue, in your particular case I checked a few servers and they all seem to have the proper revision of the Q21865369 item (1971820313 at the time of writing):

select * { wd:Q21865369 schema:version ?v . }

Try it!

Without more evidences of your particular issue it is almost impossible for us to investigate further. When it happens again please let us know rapidly via this same page possibly pin-pointing the revision that you think was not propagated properly to the query service, I'm sorry for the inconvenience. DCausse (WMF) (talk) 09:50, 12 September 2023 (UTC)

@DCausse (WMF): Thanks for asking for more evidence. I have marked the 2 queries above as

• query 1 for landform (Q271669) (?item wdt:P31/wdt:P279* wd:Q271669 .) returns set 1
• query 2 for mountain (Q8502) (?item wdt:P31/wdt:P279* wd:Q8502 .) returns set 2

and added the only diff.

As mountain (Q8502) subclass of (P279) elevation (Q106589819) & elevation (Q106589819) subclass of (P279) landform (Q271669), I would expect the result set of query 2 (set 2) to be a subset of the result set of query 1 (set 1), namely the intersection of set 1 with the set of all items with instance of (P31) mountain (Q8502). Especially if Sauernkogel (Q21865369) instance of (P31) mountain (Q8502) (and nothing else) and does not show up as an element in set 2, it must not show up in set 1 as well. The other way round, all mountain (Q8502) in set 1 must also be elements in set 2.

But this is not the case. Still running query 1 returns Sauernkogel (Q21865369), while running query 2 doesn't. You can run query 1, then query 2, then again query 1 and the error condition will persist. Running query 1 two times with the same results (1102 matches in my case at the moment) will give you the evidence, that nothing has changed in the data.

I tried to simplify the two queries above and reproduce analogous behaviour. But sorry, I did not make it, either the behaviour is as expected or the modified queries run into timeout. I suspect that erroneous behaviour described above is the result of some improperly catched timeout condition, where some cached results are return instead of an error. I'm not talking about an update lag, running queries 1, 2 and 1 again clearly proves that there is no data lag behind the problem. Hope the condition persists long enough to give you a chance to analyse the erroneous behaviour. best --Herzi Pinki (talk) 20:53, 12 September 2023 (UTC)

@Herzi Pinki: thanks for clarifying your problem, I did try to restrict the query to avoid the timeouts and make the testing easier putting VALUES(?item) {(wd:Q21865369)} and also failed to reproduce the issue, I can see the effect of the filter not exists { ?item wdt:P131 ?wo } properly excluding Sauernkogel (Q21865369) in both scenario. At a glance I don't have a compelling explanation that might explain the behavior you are experiencing I'd be leaning towards some internal caching or optimization bugs within blazegraph. DCausse (WMF) (talk) 09:05, 13 September 2023 (UTC)

@DCausse (WMF): analysing complicated cases takes time. I'm patient. best --Herzi Pinki (talk) 15:30, 14 September 2023 (UTC)

Seeing the pin in the haystack isn't that easy. But if, it is great luck. If you run such a query only once you will never know, whether results are correct, or not. Unless the root cause is identified and fixed, you cannot trust in any query result. What a pity that the precious wrong result is gone now. --Herzi Pinki (talk) 10:06, 18 September 2023 (UTC)

@DCausse (WMF): another case: Query (with landform (Q271669)) lists Östliche Praxmarerkarspitze (Q67083874), while Query (with mountain (Q8502)) doesn't. --Herzi Pinki (talk) 09:11, 2 November 2023 (UTC)

Thanks for filing this ticket! Discussion should continue there. DCausse (WMF) (talk) 08:41, 6 November 2023 (UTC)

Mobil

Url eklediğiniz sitelerime giriş kullanıcı girişi yapamıyorum Uralvolkan89 (talk) 20:01, 20 January 2024 (UTC)

BCE dates are not sorted correctly

I was using a query to find items with badly ordered start/end times (there are a lot of these, it would be nice if we had a constraint for this), and found that BCE dates are actually sorted backwards when using the < operator.

#title: items that end before starting
SELECT ?a WHERE {
  ?a wdt:P580 ?start.
  ?a wdt:P582 ?end.
  FILTER (?end < ?start)
  # wikidata bug: BCE dates are not ordered correctly
  FILTER ("0001-01-01" ^^ xsd:dateTime < ?end)
}

items that end before starting

Italic Binarycat32 (talk) 20:14, 23 January 2024 (UTC)

@Binarycat32: I don’t see any BCE results in that query (which would be correct, given that the last FILTER should filter them out); can you give an example item that’s affected? Lucas Werkmeister (WMDE) (talk) 12:29, 24 January 2024 (UTC)

bug with autocompletion of datatypes

The core of the issue is that ^ is not considered a metachar by the completion engine.

Replication steps:

1. go to
2. type "1"^^xsd:
3. activate autocompletion with ctrl+space

Workaround: type a space after ^^. This works, but it doesn't look great and it diverges from the common practices for formatting SPARQL. Binarycat32 (talk) 20:23, 23 January 2024 (UTC)

Same in property paths. Type wdt:P31|wdt: no autocompletion, wdt:P31| wdt: autocomplete works. author  TomT0m / talk page 09:48, 24 January 2024 (UTC)

Normal_or_not_?

Tracked in Phabricator
Task T356161

Moving this conversation over as it seem related to search. -Mohammed Abdulai (WMDE) (talk) 12:09, 29 January 2024 (UTC)

Is it normal that a "unknown value" in the commons query service seems to be referenced in two depicts statements <https://commons.wikimedia.org/.well-known/genid/ed0711ecce1da741f2f6fa351743e4a2> I was toying around a query to check which has the most depiction of commons, got the filter to remove the "some value" wrong so I expected to see only "one" in the "count" column, but this one had 2 ! author  TomT0m / talk page 12:26, 21 January 2024 (UTC)

the query author  TomT0m / talk page 12:38, 21 January 2024 (UTC)

@TomT0m: this is indeed very strange, the "some value" (or "unknown value") ids are generated using a hash of its "constituents" and I'm surprised that they could be used by two different commons entity unless we have a collision (which seems unlikely). Looking at where they come from I see it from File:Главный_редактор_Baltnews_А._Стариков.jpg (M130887689) and File:Главный_редактор_Baltnews_А._Стариков_(cropped).jpg (M115086921) which appears to be the same photos depicting the same person...

On both media items I see the same statement identifier being reused by both entities:

select * { ?e ?p sdcs:M130887689-83501cde-4a4b-a7d0-9832-5f1982be0c41 }

Try it!

This seems like a serious bug in MediaInfo, two statements can't have the same identifier. I'll file a ticket shortly and tag this discussion appropriately. DCausse (WMF) (talk) 22:18, 29 January 2024 (UTC)

WDQS wikibase:around issue

Tracked in Phabricator
Task T362074

Moving this conversation over as it seem more related to search. -Mohammed Abdulai (WMDE) (talk) 11:13, 8 April 2024 (UTC)

The wikibase:around service seems to be exhibiting a failure illustrated by the following two queries. The first query looks for items centered on the coordinate of Hack Green Secret Nuclear Bunker (Q5637175). It should return Hack Green Secret Nuclear Bunker (Q5637175) as one of the items found, but does not. The second query looks for items centered on the coordinate of Hack House Farmhouse (Q62130029), which was the single result in the first query. It finds itself, and it also finds Hack Green Secret Nuclear Bunker (Q5637175). This second query demonstrates that wikibase:around should return items having centre-point coordinates, and also demonstrates that Hack Green Secret Nuclear Bunker (Q5637175) data is in the triplestore and accessible to a wikibase:around query; and so the issue is that Hack Green Secret Nuclear Bunker (Q5637175) is not being returned by the first query. Why does the first query not return Hack Green Secret Nuclear Bunker (Q5637175)?

SELECT DISTINCT ?item ?itemLabel WHERE 
{
  wd:Q5637175 wdt:P625 ?targetLoc. # hack green bunker
  SERVICE wikibase:around {
    ?item wdt:P625 ?location.
    bd:serviceParam wikibase:center ?targetLoc.
    bd:serviceParam wikibase:radius "0.3".
    bd:serviceParam wikibase:distance ?dist.
 }
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

Try it!

SELECT DISTINCT ?item ?itemLabel WHERE 
{
  wd:Q62130029 wdt:P625 ?targetLoc. # hack green bunker
  SERVICE wikibase:around {
    ?item wdt:P625 ?location.
    bd:serviceParam wikibase:center ?targetLoc.
    bd:serviceParam wikibase:radius "0.3".
    bd:serviceParam wikibase:distance ?dist.
 }
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

Try it!

--Tagishsimon (talk) 21:52, 6 April 2024 (UTC)

Thanks for the report, this is indeed very strange and I suspect a bug in blazegraph, I filed phab:T362074 to keep track of the problem. DCausse (WMF) (talk) 13:13, 8 April 2024 (UTC)

Stale values in SparQL query result

Tracked in Phabricator
Task T362977

This query:

SELECT ?p ?pLabel ?id ?web {
  ?p wdt:P12614 ?id .
  wd:P12614 wdt:P1630 ?fmt.
    BIND(IRI(REPLACE(?id, "(^.*)", ?fmt)) AS ?web)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ru,en"  }
}

Try it!

Doesn't show these items:

SELECT * WHERE {
  VALUES ?el {
    wd:Q51670636
    wd:Q968274
    wd:Q4314307
    wd:Q4349600
  }
  ?el schema:dateModified ?v.
}

Try it!

For some reason changes are not reflected in query service for >1 day. Podbrushkin (talk) 09:40, 19 April 2024 (UTC)

Thanks for reporting this issue, I filed phab:T362977 to investigate the cause and possibly fix the issue. DCausse (WMF) (talk) 12:32, 19 April 2024 (UTC)

Example Query not working

I am trying to download the boiling points and melting points of a range of chemicals. I saw the example 'boiling points of alkanes' query in SPARQL, but when I ran it it gave no results at all.

# Boiling points of alkanes

SELECT DISTINCT ?comp ?compLabel ?formula ?bp ?bpUnit ?bpUnitLabel WHERE {
  ?comp wdt:P31/wdt:P279* wd:Q41581 ;
        wdt:P274 ?formula ;
        p:P2102 [
          ps:P2102 ?bp ;
          psv:P2102/wikibase:quantityUnit ?bpUnit
        ] .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} ORDER BY DESC(?bpUnit) ASC(?bp)

Try it!

2A0E:CB01:B3:B900:A948:630D:162E:D584 18:22, 7 May 2024 (UTC)

The model seems to have changed, this works if you remove the "wdt:P31/" : https://w.wiki/9$X2 author  TomT0m / talk page 18:25, 7 May 2024 (UTC)

Thank you that does work for that set. 152.78.0.22 08:19, 8 May 2024 (UTC)

Query build by query builder not working: compounds with both melting point and boiling point

When I try to look for more than one property, using the query builder, i.e. I want something that has both a boiling point and a melting point, but I don't care what values these have, I use the query builder and get no answers. The query it builds is below.

SELECT DISTINCT ?item ?itemLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
  {
    SELECT DISTINCT ?item WHERE {
      ?item p:P2102 ?statement0.
      ?statement0 (psv:P2102/wikibase:quantityAmount) ?numericQuantity.
      ?item p:P2101 ?statement1.
      ?statement1 (psv:P2101/wikibase:quantityAmount) ?numericQuantity.
    }
    LIMIT 100
  }
}

Try it!

I have checked and I can get lots of results with both melting point and boiling point values on their own, however nothing while together. There are definitely a lot of compounds with both melting point and boiling point, what am I doing wrong? 152.78.0.22 08:21, 8 May 2024 (UTC)