Page MenuHomePhabricator

^^xsd:integer is not properly parsed by the Wikidata Query UI
Closed, ResolvedPublic

Description

As a user of the Wikidata Query UI I want to properly format my SPARQL queries with "<number>"^^xsd:integer using the query helper and the format button in order to improve them while having the same results

Problem: Queries using "<number>"^^xsd:integer are not properly parsed by the Wikidata Query UI. When using the query helper or the format button, "<number>"^^xsd:integer is replaced with <number>, which is not equivalent. This was reported by User:Tagishsimon at https://twitter.com/statuses/1050910146589876224 (thanks!).

Example: I can run the query...

SELECT ?date_node WHERE {
  ?date_node wikibase:timePrecision "11"^^xsd:integer .
}
LIMIT 5

... but, when I use the format button, I cannot run the resulting query...

SELECT ?date_node WHERE { ?date_node wikibase:timePrecision 11. }
LIMIT 5

Screenshots/mockups:

BDD
GIVEN I am on the Wikidata Query UI
AND I write a correct, executable SPARQL query with "<number>"^^xsd:integer
WHEN I press the format button
THEN the resulting SPARQL query can be executed
AND has the same results as the original one

Acceptance criteria:

Open questions:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The task description is a bit confusing :) on its own, <number> is equivalent to "number"^^xsd:integer, both according to the spec (SPARQL 1.1 Query Language, § 4.1.2) and according to experiment (query). However, BlazeGraph fails to parse an integer literal immediately followed by a (triple-terminating) period, attempting to parse it as a decimal or double literal instead. I’m not sure if this is allowed by the spec or not, but I suppose it doesn’t matter that much.

The workaround is to add a space between the literal and the period (11.11 .), which prevents the “decimal or double literal” interpretation. This could either be done as an improvement to SPARQL.js’ stringification (though it depends on what the spec says on this, I guess), or as a post-processing step afterwards (something like .replace(/(\d)\.(?!\d)/g, '$1 .')).

Thanks, and sorry for the confusing description. I just hadn't investigated the cause of the problem. Would it be a good solution to always add a space before the triple-terminating period?

You mean, for any triple? It would work, but IMHO that’s uglier :)

I quickly checked how some SPARQL servers parse SELECT (1. AS ?x) (DATATYPE(?x) AS ?dt) {}:

  • BlazeGraph: "1."^^xsd:decimal
  • Virtuoso: "1"^^xsd:decimal
  • Fuseki: parse error (expecting AS at .)

So whatever the spec says, implementations seem to do very different things. I’ve opened SPARQL.js#66 to request an upstream fix.

Change 484266 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[wikidata/query/gui@master] Update sparqljs to newest version

https://gerrit.wikimedia.org/r/484266

Change 484266 merged by jenkins-bot:
[wikidata/query/gui@master] Update sparqljs to newest version

https://gerrit.wikimedia.org/r/484266

abian assigned this task to Lucas_Werkmeister_WMDE.

This was fixed a long time ago. Thanks!