I used queries like this to compare counts between wikidata and our wdtruthy service.

• For the first 2 queries we use count(distinct ?x): they have prop path but a small result population
• For the other queries we use count(*) because it's much faster

I see the count triples on recently modified entities:

The full dump is 15B triples (you can see this here https://query.wikidata.org/bigdata/ldf).
WDtruthy is 6.5B triples (we have it in GraphDB, continuously updating).
Adding the counts will add 320M, or 5%.

The following query (from https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization#Distinct_term_scan,_and_group_by_and_count_optimization)

SELECT ?p (COUNT(?p) AS ?count)
WHERE { [] ?p [] . }
GROUP BY ?p order by desc(?count)

when ran at the WD query service shows the interesting counts:

• wikibase:statements 107093728
• wikibase:identifiers 105929733
• wikibase:sitelinks 105928930

I posted https://github.com/w3c/sparql-dev/issues/192 to collect info about what various SPARQL processors do in such cases.
Blazegraph allows it for certain situations:

• COUNT
• SAMPLE
• identity rebinding
• expression rebinding (not aggregate): but returns no rows

Reading through the spec:

• https://www.w3.org/TR/sparql11-query/#bind: "The variable introduced by the BIND clause must not have been used in the group graph pattern up to the point of use in BIND."
• https://www.w3.org/TR/sparql11-query/#selectExpressions: "The rules of assignment in SELECT expression are the same as for assignment in BIND. The expression combines variable bindings already in the query solution, or defined earlier in the SELECT clause. The variable may be used in an expression later in the same SELECT clause and may not be be assigned again in the same SELECT clause."
  • This says you can't "assign" the same var twice in SELECT and that vars are brought forward from BIND, but not explicitly that you can't "reassign" from BIND to SELECT

Thanks everyone and especially @Jheald for the valuable info.

https://github.com/Sophox/sophox/issues/17 is about GeoSPARQL in Sophox, the OpenStreetMap SPARQL endpoint.
It uses Blazegraph (and Wikibase for OSM tags.keys).

Turns out that VIAF pages (from which I copied the values) do have such weird invisible Unicode chars. Printed in hex:

3337 3237 37e2 808f e280 8f

@Mahir256 : see T30443 for a validation of the WD dump with rdf4j, and it still appears.

Bart Hanssens tried to validate the WD dump with rdf4j:
https://github.com/barthanssens/rdf4j-bigfile-validator/blob/main/log.txt
'孟慶雲' was not recognised as a language literal, and could not be verified, with language zh-classical

@Ivan

see updated report immediately after fixing several items