SparQL query throws unexpected error about java-client-api

[rjrudin]

The syntax error is correct - "12." is interpreted as a symbol, and the syntax error thus occurs because the two lines in your statement run together.

This section from the MarkLogic Semantics docs shows a number of examples for constructing query clauses correctly. I like this Apache Jena tutorial as well for when I need to remember basic SPARQL syntax. Those should help you with constructing your desired SPARQL queries.

[Cynthia-77]

The syntax error is correct - "12." is interpreted as a symbol, and the syntax error thus occurs because the two lines in your statement run together.

This section from the MarkLogic Semantics docs shows a number of examples for constructing query clauses correctly. I like this Apache Jena tutorial as well for when I need to remember basic SPARQL syntax. Those should help you with constructing your desired SPARQL queries.

If explicitly declaring the data type of integer "12", the SparQL query can be executed correctly in MarkLogic. Like the following:

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT *
WHERE { 
        ?var1 ?var2 "12"^^xsd:integer.
        <http://JohnSmith> <http://livesIn> ?var3.
      }

Do all integers in a SparQL query need to explicitly declare their data type to execute in MarkLogic?

But the SparQL documentation states that "integers can be written directly (without quotation marks and an explicit datatype IRI) and are interpreted as typed literals of datatype xsd:integer".

And this query can be executed correctly in Apache Jena.

SELECT *
WHERE { 
        ?var1 ?var2 12.
        <http://JohnSmith> <http://livesIn> ?var3.
      }

Does MarkLogic consider to support this feature in the future?

[jpcs]

The grammar production for a decimal number changed between SPARQL 1.0 and SPARQL 1.1:

https://www.w3.org/TR/rdf-sparql-query/#rDECIMAL
https://www.w3.org/TR/sparql11-query/#rDECIMAL

It looks like MarkLogic is still using the SPARQL 1.0 definition of a decimal, which means that the "12." in your query is treated as a decimal literal, rather than "12" followed by ".".