1

Write the following RDF data into MarkLogic:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://John> <http://have> 10 .
<http://Peter> <http://have> "10"^^xsd:double .

Then execute the following query:

SELECT *
WHERE { ?s ?p 10. }

The query result is:

?s ?p
<http://John> <http://have>
<http://Peter> <http://have>

In RDF document, RDF term is equal if and only if the value and data type are both the same.

Literal term equality: Two literals are term-equal (the same RDF literal) if and only if the two lexical forms, the two datatype IRIs, and the two language tags (if any) compare equal, character by character. Thus, two literals can have the same value without being the same RDF term.

https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

It seems that MarkLogic does not follow the RDF specification?

Expected query result:

The expected query result is:

?s ?p
<http://John> <http://have>

Alternatives

Executing the SparQL query in Query Console and with Java Client API will both get the unexpected query result.

This query can return the expected query result in Apache Jena and RDF4j.

Can someone give me an answer or a hint about it?

uniqueR
  • 51
  • 1

1 Answers1

3

A triple store that does that is not automatically wrong.

Try:

{ ?s ?p ?x . FILTER (sameTerm(?x, 10)}

{ ?s ?p ?x . FILTER (?x = 10) }

and also

Also try:

with 010 and +10, "010^^xsd:integer

and explore the lexical forms:

FILTER(str(?x) = "10")

The use cases for both value-based matching and term-based matching exist.

SPARQL query does not say whether the data loaded is exactly the data queried (by design). Several store do variations of value-processing as default behaviour. Jena does for TDB2 but keeps datatypes apart (TDB1 conflating datatypes was less popular).

It depends on what use case they are targetting. If you want a particular effect, then use a FILTER form of the query assuming data was not pre-processed on loading.

See the answer on Unexpected data writing result in MarkLogic

See https://www.w3.org/TR/sparql11-entailment/#CanonicalLit for the discussion that D-entailment gives many, many answers even with a restriction to canonical lexical forms.

AndyS
  • 16,345
  • 17
  • 21