datatype of constant literal is ignored (same for language tag)

[pchampin]

When a literal is used as the value of rr:constant, its datatype is ignored and it is rendered as a string instead.
Example:
data.json

[ { "id": "0", "foo": "bar"  } ] 

map.ttl

@prefix rml: <http://semweb.mmlab.be/ns/rml#> .
@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix ql: <http://semweb.mmlab.be/ns/ql#> .

 [
    a rr:TriplesMap;
    rml:logicalSource [
      rml:source "data.json" ;
      rml:referenceFormulation ql:JSONPath ;
      rml:iterator "$[*]";
    ];
    rr:subjectMap [
      rr:template "https://example.org/instances/{id}";
    ];
    rr:predicateObjectMap [
      rr:predicate <http://example.org/ns/p> ;
      rr:object true ;         # <-- the constant is an xsd:boolean
    ];
  ] .

The result is

<https://example.org/instances/0> <http://example.org/ns/p> "true" .

(note that the object is a string)

I would have expected this:

<https://example.org/instances/0> <http://example.org/ns/p> "false"^^<http://www.w3.org/2001/XMLSchema#boolean> .

I can work around this issue by replacing rr:object true with

rr:objectMap [ rr:constant "true"; rr:datatype xsd:boolean ]

but that should not be necessary.

[DylanVanAssche]

Hi! I'm afraid this is intended by R2RML: https://www.w3.org/TR/r2rml/#constant

rr:object is a shortcut for rr:objectMap [ rr:constant true; ].
If there is no datatype given, it defaults to strings.

If you want to see different behavior in the future, I suggest you open an issue at https://github.com/kg-construct/rml-core.

[pchampin]

@DylanVanAssche thanks for your response. However, I disagree with the following:

rr:object is a shortcut for rr:objectMap [ rr:constant true; ].
If there is no datatype given, it defaults to strings.

Reading R2RML Section 7.1 Constant RDF Terms (rr:constant):

The constant value of a constant-valued term map is the RDF term that is the value of its rr:constant property.

(emphasis is mine)

Please note that the value of rr:object/rr:constant is not "true" (a string), but true, an alias for "true"^^xsd:boolean. So the resulting object in the generated RDF should be this RDF term, with the xsd:boolean datatype.

[DylanVanAssche]

Interesting observation, I have a feeling this is related as well to the RML IO Registry in the new RML.
In that registry we define as a community the 'natural mapping' of data types for each reference formulation.
In this case the reference formulation is not used, but the datatype is given indirectly through the mapping without a rr:datatype/rml:datatype.

Maybe this needs to be defined properly in RML-Core going forward?

I think it is only the case for booleans?

[pchampin]

I think it is only the case for booleans?

no, I just did the test replacing true (a.k.a. "true"^^xsd:boolean) with 42 (a.k.a. "42"^^xsd:integer) and I also get a string instead.

[DylanVanAssche]

no, I just did the test replacing true (a.k.a. "true"^^xsd:boolean) with 42 (a.k.a. "42"^^xsd:integer) and I also get a string instead.

Yes, I expected that. There are a few cases when this is possible I think?

• Booleans: true, false
• Integers: 42
• Floats/doubles: 42.1

That's all I think?

[pchampin]

I have a feeling this is related as well to the RML IO Registry in the new RML.
In that registry we define as a community the 'natural mapping' of data types for each reference formulation.

I'm not an expert of the RML specs, but I would not expect the behaviour of rml:constant to depend on the logical source, since by definition (at least in R2RML), a constant map is entirely specified by the mapping file, and does not depend on the input data...

[pchampin]

Yes, I expected that. There are a few cases when this is possible I think?

* Booleans: `true`, `false`

* Integers: `42`

* Floats/doubles: `42.1`

not exactly. In turtle, 42.1 is an xsd:decimal, 42.1e0 is an xsd:double.

That's all I think?

Yes, that's all.

[DylanVanAssche]

I'm not an expert of the RML specs, but I would not expect the behaviour of rml:constant to depend on the logical source, since by definition (at least in R2RML), a constant map is entirely specified by the mapping file, and does not depend on the input data...

Yes I agree, but I mean: we define there for reference formulations already the natural datatype mapping a processor must do and how. We could also add another entry in the registry saying how to map these constants correctly, as you list here:

42.1 == xsd:decimal while 41.1e0 == xsd:double

combined with some test cases we avoid this 'detail' to be forgotten by implementations?

[pchampin]

We could also add another entry in the registry saying how to map these constants correctly

IMO, RML should not say how to map these constants correctly. The Turtle parser should map these constant to the corresponding RDF term according to the Turtle specification. RML should only be concerned with the RDF terms that come out of the Turtle parsing. It should not even have (or need) access to how the RDF term was serialized in Turtle (e.g. 42, "42"^^xsd:integer, "42"^^<http://www.w3.org/2001/XMLSchema#integer>).

[DylanVanAssche]

I agree with that, just stating that Processors must honor these RDF terms when reading the RML mapping instead of just adding xsd:string everywhere for rr:constant? Defining this literally helps a lot IMO.

[pchampin]

I agree with that, just stating that Processors must honor these RDF terms when reading the RML mapping

§ 8.1 Constant RDF Terms of RML-Core says:

The constant value of the rml:constant property is the generated RDF Term.

For me, there is no ambiguity here: the generated RDF term is the value of rml:constant. If this value is a literal, it should be kept as a whole, with its datatype or language type (I notice that language tags are also ignored by RMLMapper currently -- so I updated the title of this issue).

instead of just adding xsd:string everywhere for rr:constant?

I assume that you mean "adding rr:datatype xsd:string everywhere"? I would argue that this irrelevant, but that the RML-core IO could be made more explicit about that. Let me explain:

§ 8.6 Datatypes of Literals starts with:

A datatypeable term map is a term map with a term type of rml:Literal that does not have a specified language map.

It refers to the definition of term type, which itself starts with:

The term type of a reference-valued term map or template-valued term map determines the kind of generated RDF term (IRIs, blank nodes or literals).

Note that only reference-valued and template-valued term maps may have a term type (and therefore, may have a datatype map), not constant-valued term maps. So my reading is that rml:constant (or rr:constant) should not coexist with rml:datatype (or rr:datatype), and if it does, rml:datatype should be ignored. This would be consistent with how R2RML deals with rr:constant, by the way (see https://www.w3.org/TR/r2rml/#dfn-generated-rdf-term).

So the RML-Core spec could be improved in
§ 8.6 Datatypes of Literals:

A datatypeable term map is a reference-valued term map or template-valued term map with a term type of rml:Literal that does not have a specified language map.

and similarly in § 8.5 Language tags which has the exact same kind of language.

[DylanVanAssche]

For me, there is no ambiguity here: the generated RDF term is the value of rml:constant. If this value is a literal, it should be kept as a whole, with its datatype or language type (I notice that language tags are also ignored by RMLMapper currently -- so I updated the title of this issue).

I am very sure this is for almost any existing implementation currently. If it is clear enough in the spec, at least we need to add a test case in RML-Core to verify this behavior :)

I assume that you mean "adding rr:datatype xsd:string everywhere"? I would argue that this irrelevant, but that the RML-core IO could be made more explicit about that. Let me explain:

No, I mean: this happens currently internally in almost any engine, as you pointed out, this behavior ain't correct in this case :)

So my reading is that rml:constant (or rr:constant) should not coexist with rml:datatype (or rr:datatype), and if it does, rml:datatype should be ignored. This would be consistent with how R2RML deals with rr:constant, by the way (see https://www.w3.org/TR/r2rml/#dfn-generated-rdf-term).

Right! Well as you stated a paragraph further, it needs improvements in the spec. Thanks a lot for spotting this!