Wikidata:Report a technical problem/WDQS and Search

This page is dedicated to questions and bug reports about the parts of Wikidata's software that are handled by WMF's Search Platform team, such as the Query Service and various search features.

If you have a question or request about another topic, please use this page instead.
If you need guidance with creating a query, please use request a query.
If WDQS lags, check Grafana. If the lag isn't visible there or is large, please report it here, ideally including items edited on Wikidata, but not updated on the server.

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/12.

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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

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)[reply]

@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)[reply]

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

Mobil

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

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)[reply]

@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)[reply]

bug with autocompletion of datatypes

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

Replication steps:

go to
type "1"^^xsd:
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)[reply]

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)[reply]

This is phab:T182969. - Nikki (talk) 14:00, 3 August 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

Your query is looking for boiling point = ?numericQuantity and melting point = ?numericQuantity; i.e. both having the same numeric value. To allow them to be different, you can change them to ?numericQuantity0 and ?numericQuantity1. If you need further help with SPARQL, the place to go is Wikidata:Request a query. –LiberatorG (talk) 22:45, 15 May 2024 (UTC)[reply]

Incorrect output of articles with redirect badge

A query to output items with sitelink to redirect (Q70893996) badges returns a page without such a badge.

SELECT ?item ?ruwiki
WHERE {
  ?item wdt:P31 ?set
   VALUES ?set {     
    wd:Q201658
    }
  ?ruwiki schema:about ?item;
         schema:isPartOf <https://ru.wikipedia.org/>.
  ?ruwiki wikibase:badge wd:Q70893996.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ru". }
}
GROUP BY ?item ?ruwiki
ORDER BY ASC(?ruwikiLabel)

Try it!

Solidest (talk) 22:52, 8 May 2024 (UTC)[reply]

@Solidest This is probably a known issue, caused by the bug of the wikibase sparql that does not move the badge when a page is renamed.

Tracked in Phabricator
Task T323239

A workaround is to add / remove the badge on the Wikidata query UI to force an update on items linked to articles with incorrect badges. author TomT0m / talk page 08:44, 9 May 2024 (UTC)[reply]

The article was renamed almost a year ago and apparently its that bug, thanks for the tip. Disabling/enabling that badge and replacing it with another one fixed it. Solidest (talk) 09:04, 9 May 2024 (UTC)[reply]

Item not searchable by initial part of Label or its alias

Tracked in Phabricator
Task T364837

@Kimeerat brought to my attention a problem with a newly created data item. For Q125918173, the item is not searchable by the initial words or prompted when typing the Label or alias in the search box. I tried to remove and add alias, and added label in Telugu to try to solve the issue, but failed. Arjunaraoc (talk) 05:13, 14 May 2024 (UTC)[reply]

@Arjunaraoc thanks for the report, Telangana State GIS Portal (Q125918173) appears to be missing from one of our search clusters (codfw), filed phab:T364837 to investigate and fix the issue. DCausse (WMF) (talk) 10:46, 14 May 2024 (UTC)[reply]

Fairly new property unable to be searched by its label, alias, or P number

Property The Law Dictionary entry (P12705) was created last week. On both my home and work computers, when I use the search box to search for it by its label, alias, or P #, I do not get it in the results. Also, when I try to add a statement with this property, if I type in part of the title in the label or alias, it is not found. I have to type in P12705 to be able to add the statement in an item or lexeme. I am not having any of these problems with any other property, including one I created just last night, population by native language (P12712). If I type P12712 in the search box, I get the property in the results, and if I type "population by native" in the search box, it is also the first in the results. AdamSeattle (talk) 20:51, 14 May 2024 (UTC)[reply]

@AdamSeattle Thanks for reporting this problem. The issue you are facing has the same cause as the issue reported above. For about 7 days between May 7th at 23:30:00 UTC and May 14th 16:15:00 UTC most edits on wikidata failed to be properly indexed in the search cluster located in Dallas, our other search cluster in Virginia did not face the same issue. This explains why only a portion of wikidata users were affected by the problem (the search cluster is chosen based on the location of the user accessing wikidata). The issue has been fixed on May 14th 16:15:00 UTC and this explains why you were able to find population by native language (P12712) but not The Law Dictionary entry (P12705). We are currently re-indexing all the edits that happened during that period. DCausse (WMF) (talk) 07:43, 15 May 2024 (UTC)[reply]

query.wikidata.org – List of examples is empty

query.wikidata.org used to provide a library of examples. If I now click on the examples button, an overlay opens, but the list of examples seems to be empty. It just displays "Type to filter" and shows the number 0 on the left.

The examples interface worked normally about a month ago and I noticed the current behaviour one week ago (2024-06-06) Hbuschme (talk) 15:46, 13 June 2024 (UTC)[reply]

OK, I found a related discussion: https://phabricator.wikimedia.org/T366871 Hbuschme (talk) 15:49, 13 June 2024 (UTC)[reply]

test.wikidata.org does not index new items label

- https://test.wikidata.org/w/index.php?search=eyvmdqnhcjhfziqs is not found although it exists at https://test.wikidata.org/wiki/Q234771 (created June 2024)

- https://test.wikidata.org/w/index.php?search=vtmadqvhkhiabiqz is found to match https://test.wikidata.org/wiki/Q233313 (created December 2023)

Is it a known issue with the indexor? Natct (talk) 09:39, 19 June 2024 (UTC)[reply]

moved from Wikidata:Report a technical problem --Lucas Werkmeister (WMDE) (talk) 10:00, 19 June 2024 (UTC)[reply]

@Natct thanks for the report, we experienced a failure of the indexing pipeline causing all updates to stall on June 19 between 03:00 and 15:30 UTC. The system is currently catching up for all past updates and might take several hours to fully absorb its backlog. The particular item you mention seems to have been indexed since then but there are other page updates made during that period that might not yet be in the search index. We are sorry for the inconvenience. DCausse (WMF) (talk) 19:41, 19 June 2024 (UTC)[reply]

@DCausse (WMF): fwiw, I have 6 items updated on the 19 & 20 June - https://w.wiki/ASz6 - for which WDQS has not been updated ... on the production WDQS, not test. Only one of them was edited within the June 19 between 03:00 and 15:30 UTC window, afaics. It's not a prolem for me, more of a FYI. --Tagishsimon (talk) 16:01, 21 June 2024 (UTC)[reply]

@Tagishsimon thanks for the report, I think this particular problem is more related to a broader issue we have with the event platform not being able to deliver all events coming out of wikidata. The impact on WDQS is tracked at phab:T362977, sadly I could only identify one of the six items you mentioned in your message (using the query you provided). There is sadly no consensus yet on how to improve the system but discussions are happening between various teams at the WMF about this. DCausse (WMF) (talk) 09:01, 27 June 2024 (UTC)[reply]

@DCausse (WMF)@Lucas Werkmeister (WMDE)@Tagishsimon

As of today, we checked and it is indexed in less than 10 minutes, thank you folks! Natct (talk) 08:20, 26 June 2024 (UTC)[reply]

Can't switch language

I want to get a description inside JSON in other languages via the following URL, although I change the “language” parameter, I always get the description text in English. What should I do to get this in another specified language? For example, the text does not change in these languages "tt" and "ru"

URL: https://www.wikidata.org/w/api.php?action=wbsearchentities&format=json&search=apple&language=en Axmetxan (talk) 20:37, 21 June 2024 (UTC)[reply]

Problem solved: uselang= controls the language in which results are returned, language= controls the language in which the search happens

Concern about Wikidata Graph Split

Thanks to @DCausse (WMF) for responding to my queries about the Graph Split at Wikidata talk:SPARQL query service/WDQS graph split/WDQS Split Refinement and directing me instead to this page. I have a thesis project here Wikidata:WikiProject LSEThesisProject which contains multiple queries linking our thesis metadata with other entities in Wikidata, and includes links to other visualisation tools such as Histropedia. Thank you for the sample rewritten queries from the NZ thesis project - they look complex for my basic level of SPARQL knowledge, so it looks as if considerable upskilling will be required to add federation into the mix when attempting to write new SPARQL queries, meaning it will be a really extensive piece of work to maintain our thesis project page. I wondered if there was a timescale for the split so that we can do some local planning as this looks to be quite problematic for us. I'm also concerned that the complexity of federated SPARQL queries will impact other work that we had planned with Wikidata so we may need to consider whether to halt this work, and again a timescale would help with that decision making.

I'll ask a separate question on the Scholia Github pages about what the impact of the graph split on Scholia will be, but am interested in any comments on that too.

Thanks for your help, best wishes @HelsKRW HelsKRW (talk) 09:04, 1 July 2024 (UTC)[reply]

@HelsKRW Thanks for your question, there will be a transition period of at least 6 months starting from the time we expose the new split graph endpoints and the time we stop serving the full graph, we are hoping to provide these endpoints during this month. We will communicate about this more precisely once the endpoints are available. It is hard to anticipate how this transition period is going to happen but I'm sure we will find solutions if some users are struggling to rewrite their queries or require more time to do so. DCausse (WMF) (talk) 08:19, 2 July 2024 (UTC)[reply]

Thanks for coming back to me @DCausse (WMF). During the transition period will all existing SPARQL queries continue to work? I was about to share Wikidata:WikiProject LSEThesisProject with some colleagues for their further use, but if all the SPARQL queries will break this month I might need to change my plans. If they'll work for 6 months, during which I can hopefully find some help to re-write them then it might be less problematic. Thanks again for your help, best wishes @HelsKRW HelsKRW (talk) 13:24, 5 July 2024 (UTC)[reply]

@HelsKRW absolutely, during these 6 months existing queries will continue to work exactly the same way, for users to transition to the split graph they will have to use another endpoint but all this will be properly communicated and explained very soon. DCausse (WMF) (talk) 14:02, 5 July 2024 (UTC)[reply]

That's really helpful - thank you @DCausse (WMF) HelsKRW (talk) 07:07, 9 July 2024 (UTC)[reply]

behaviour near timeout

I'm running some queries without going through the interface. A few of these queries appear to take almost exactly 60 seconds but return far too few results. Does anyone know what happens if the timeout occurs after the query is done but the results are still being gathered together?

Here is one of these queries:

SELECT DISTINCT ?s WHERE { ?s wdt:P279* wd:Q488383 . } Peter F. Patel-Schneider (talk) 23:04, 7 November 2024 (UTC)[reply]

It might happen that, indeed, the timeout occurs while the result are being produced to the client. In that case, because blazegraph already started producing results, the error is unfortunately injected in the middle of the results breaking the json format. This was initially reported at phab:T283962 (also related phab:T169666). It is a difficult problem to solve and I don't think an ideal solution exists, either blazegraph buffers all the solutions before producing them (at the cost of extra memory and increased latency) or the behavior that we have today where clients might be surprised to see an error in the middle of the response body. DCausse (WMF) (talk) 15:31, 8 November 2024 (UTC)[reply]

David beat me to everything I wanted to say, including the link to T169666 :D so just to clarify: if you got what looked like a complete JSON response, without a Java stack trace in the middle of it, then it’s probably a complete result set even if it seems suspiciously close to the timeout. Lucas Werkmeister (WMDE) (talk) 15:34, 8 November 2024 (UTC)[reply]

Thanks. Peter F. Patel-Schneider (talk) 16:41, 8 November 2024 (UTC)[reply]

SPARQL response for birth date is inconsistent with actual entity wikidata page

For Cleopatra I see that her birth date is stated to be "13 January 69 BCE" on her page https://www.wikidata.org/wiki/Q635

When I run a SPARQL query for birth date I get a different response (this is true for many entities see Plato Q859)

 SELECT ?itemLabel ?birthDateLabel ?birthCalendarModel ?birthDate
 WHERE {
   VALUES ?item { wd:Q635} .                       # WIKIDATA ID FOR CLEOPATRA
   ?item wdt:P31 wd:Q5.                            # INSTANCE OF HUMAN
      OPTIONAL {
       ?item p:P569 ?birthDateStatement.                      # BIRTH DATE STATEMENT (P569)
       ?birthDateStatement ps:P569 ?birthDate.                # BIRTH DATE VALUE
       ?birthDateStatement psv:P569 ?birthDateNode.           # FULL VALUE NODE FOR PRECISION
       ?birthDateNode wikibase:timePrecision ?precision ;     # EXTRACT PRECISION
                      wikibase:timeValue ?birthDate ;         # EXTRACT DATE VALUE
                      wikibase:timeCalendarModel ?birthCalendarModel. # EXTRACT CALENDAR MODEL
   }                                 
   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

The result shows birthDate as "11 January 0069 BCE" (not 13 of January like entity page) the birthDateLabel is "-0068-01-11T00:00:00Z" (not 69BCE like birth date and entity page)

QUESTIONS: Looks like the wikidata page uses the JSON (https://www.wikidata.org/wiki/Special:EntityData/Q635.json) which has different values as the SPARQL results. What can I do to get the ISO date formatted as the correct date for SPARQL? And why does the response not match the wiki data page? Which one do I trust? Destrada3000 (talk) 21:53, 25 November 2024 (UTC)[reply]

The date was entered and shown on the webpage using the Julian calendar not the Gregorian one, so it's doing the right thing. The date is stored in ISO 8601 format in the database which is what the SPARQL query returns. Infrastruktur (talk) 23:01, 25 November 2024 (UTC)[reply]

How does the wikidata page convert Julian to Gregorian calendar for display? Is there a built-in function to return it in Gregorian format? Destrada3000 (talk) 00:10, 26 November 2024 (UTC)[reply]

Minor correction: “the database” is a bit vague here. Within Wikidata’s database, the date is stored in Julian; the conversion to Proleptic Gregorian calendar happens during the RDF export and the result is stored in WDQS / Blazegraph. Wikibase implements this conversion in JulianDateTimeValueCleaner.php if you’re curious. Lucas Werkmeister (WMDE) (talk) 10:16, 26 November 2024 (UTC)[reply]

Strage LineChart UI problem with WDQS service

in the query, hdi of Switzerland and witzerland show perfectly in LineChart mode.

#Human Development Index of specified country(s)
#human development index of specified country(s)
#defaultView:LineChart
SELECT ?year ?hdi ?countryLabel WHERE {
  VALUES ?country {
    wd:Q148
    wd:Q39
    
    
    # to add another country
    # 1,uncomment the last commented line, 
    # 2,put cursor to the end of line, 
    # 3,and press CTRL+SPACE，or CTRL+ALT+SPACE, or ALT+ENTER. 
    # 4,and select first item, and press CTRL+ENTER.
    #wd:Q30
    
    }
  
  ?country p:P1081 ?statement.
  ?statement ps:P1081 ?hdi.
  ?statement pq:P585 ?date.
  
  BIND (STR(YEAR(?date)) as ?year)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

Try it!

but when i add USA(Q30) to this query, hdi of Switzerland and USA show incorrectly, the snapshot is there . when i check the table data, but there is no explictely corrupt data, please help !!!

#Human Development Index of specified country(s)
#human development index of specified country(s)
#defaultView:LineChart
SELECT ?year ?hdi ?countryLabel WHERE {
  VALUES ?country {
    wd:Q148
    wd:Q39
    
    
    # to add another country
    # 1,uncomment the last commented line, 
    # 2,put cursor to the end of line, 
    # 3,and press CTRL+SPACE，or CTRL+ALT+SPACE, or ALT+ENTER. 
    # 4,and select first item, and press CTRL+ENTER.
    wd:Q30
    
    }
  
  ?country p:P1081 ?statement.
  ?statement ps:P1081 ?hdi.
  ?statement pq:P585 ?date.
  
  BIND (STR(YEAR(?date)) as ?year)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

Try it!

but most surpriseing me it that the UI is showing perfectly after a while, but after that, it shows in incorrectly forever. Bangbang.S 07:27, 8 December 2024 (UTC)[reply]

@Bangbang.S: It looks fine on my end – Q30 and Q39 get separate lines. Which language is your query service UI set to? Lucas Werkmeister (WMDE) (talk) 09:39, 9 December 2024 (UTC)[reply]

Thank for you replying. yes you are right, when i set language to zh(中文), zh-hans(中文（简体）), zh-hant(中文（繁體）), the UI show incorrectly. but in other language, it works perfectly. what's the problem? Bangbang.S 13:24, 9 December 2024 (UTC)[reply]