It seems this feature is still undocumented (discussed in https://www.wikidata.org/wiki/Wikidata_talk:SPARQL_query_service#title:). after 5 months In my opinion it is a waste of developer time to develop something, and then don't make sure it is documented so the users can learn about it and use it - what isn't known and therefore not used , isn't useful. You should prioritize the documentation side of WDQS more. Also the wikibase:limitContinuations predicate in the MWAPI service has been undocumented for years, and many of the different result view parameters are just mentioned without explanation.

And similar to T207651 which also was declined.

This seems similar to T220829 where the rollback in https://www.wikidata.org/w/index.php?title=Q105338&diff=900796369&oldid=890602022 on 2 April 2019 wasn't propagated to Wikipedias which used a wrong image from Wikidata. It was closed because it couldn't be reproduced.

https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Full_statements clearly states: "There is no guaranteed format or meaning to the statement id." So why change an ID that should be stable when no specific format is guaranteed? Nobody should rely on any meaning in the IDs as implementation details such as this should be possible to change as need arise.

Well, it seems that the requested feature already is here, but is undocumented:

https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual/MWAPI#Pagination says:

@Lucas_Werkmeister_WMDE: Thank you for the explanation.

When I make an API call with action=query and generator=wblistentityusage, like https://en.wikipedia.org/w/api.php?action=query&generator=wblistentityusage&gwbeuentities=Q42 I get an RuntimeException:

{
    "error": {
        "code": "internal_api_error_RuntimeException",
        "info": "[66cd48ca-659d-4873-92dc-505e78f08159] Caught exception of type RuntimeException",
        "errorclass": "RuntimeException"
    },
    "servedby": "mw1382"
}

Many queries use the optimizer hint hint:Prior hint:rangeSafe true. when e.g. comparing date or number values with constants in a filter as suggested at https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization#Fixed_values_and_ranges. Is there a risc that such queries will fail or give wrong results when somevalue become IRI's, and thus the values will be of different types?

In T244341#6062871, @dcausse wrote:

What we will implement internally for the isSomeValue function won't be doing exactly STRSTARTS( STR(?o), 'http://www.wikidata.org/prop/somevalue/' ) but uses blazegraph vocabulary and inlining facilities, not sure if this answers your question though.

Yes, isLiteral should still work for properties where the real values are literals. Without knowing the internal workings of Blazegraph I would guess that it is more efficient than STRSTARTS( STR(?o), 'http://www.wikidata.org/prop/somevalue/' ) . Maybe that could be used in some way?

Here is an example where isLiteralis used to test that a value isn't somevalue: https://stackoverflow.com/questions/53102725/make-filtering-people-by-birthyear-and-deathyear-criteria-more-performative-in-s

You should be aware that also the functions isIRI or isLiteral (depending on property type) and datatype can be used and probably is used to test if a value is somevalue or a real value.

Fair enough, but the StackOverflowError seems to be a Blazegraph error, so did anyone report the issue upstream? They have a Jira issue board at https://jira.blazegraph.com/secure/Dashboard.jspa but I don't see anything about this StackOverflowError.

Why don't you close this as invalid and ask people to make correct SPARQL code?

Also wikibase:quantityUnit is affected by this - unless the strange results of this query is caused by something else:

Not a bug. Use of the Label service in automatic mode for unbound variables in "GROUP BY" isn't mentioned as supported in the user manual (https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Label_service) so cannot be expected to work.

This seems to be the same or similar to T220829 (Wikidata edit (rollback) not propagated to Wikipedia after 10 days)

Things keep changing. At the same page (https://da.wikipedia.org/w/index.php?title=Bruger:Dipsacus_fullonum/sandkasse&oldid=9957579) now the first map, with Wikidata ID's explicit in the JSON code, only show the geoshape for Croatia.

@Aklapper: Now the second map with the SPARQL query is also correct for me. But when the page was created it was only shown as a frame with the legend, but where the map should be, there was only a white empty space.

I found the same problem at huwiki at the page https://hu.wikipedia.org/wiki/Geert_Wilders by looking at the global file usage for
the wrong image at https://commons.wikimedia.org/wiki/File:MarkRutte.jpg. Again when logged in at huwíki I saw the correct image of Geert Wilders. And when I logged off, I saw the image of Mark Rutte in the infobox. Again I fixed it by a null edit of the page.

I found the system for red and blue links: An local, internal link on dawiki is blue if a page with the page name exist on enwiki, and red if no page with the name exist on enwiki. But the links don't link to enwiki.

I don't understand why this doesn't have high priority. It makes the functions mw.wikibase.getLabel( id ), mw.wikibase.getDescription( id ), and mw.wikibase.getSitelinkl( id ) unreliable for IDs obtained from a module's arguments or from statement values of type wikibase-entityid in other entities.