datatype coercion issues

On the call today, we spent a lot of time discussing issues 87 [1] and 81 [2], relating to coercion and round tripping. There are basically several things that come out of this, for which we probably need separate issues:

What is the range of the coercion operator in JSON-LD? As indicated by issue 87, it is any value (not an object or an array). This would include boolean and numeric, in addition to string. One possibility is limiting this to string, or doing it on a case-by-case basis. (boolean could coerce numeric types based on 0 or not 0, integer or double could coerce boolean or other numeric).

When is coercion applied? If applied in expansion, this implies that every term having a coercion rule with an appropriate value is placed in @value form. We currently say that native types are not converted, but we contradict ourselves for xsd:double.

Do strings not having the lexical form of a coerced datatype have coercion applied? For example does "foo" coerced to a boolean result in "foo"^^xsd:boolean, or just "foo".

For some other examples, consider the following:

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "boolean": {"@id": "xsd:boolean", "@type": "xsd:boolean"},
    "integer": {"@id": "xsd:integer", "@type": "xsd:integer"},
    "double": {"@id": "xsd:double", "@type": "double"},
    "date": {"@id": "xsd:date", "@type": "date"}
  },
  "boolean": [true, "false", 1, "0", 5, "5", 2.5, "2.5E0", "2011-03-27", "2011-03-27T01:23:45"],
  "integer": [true, "false", 1, "0", 5, "5", 2.5, "2.5E0", "2011-03-27", "2011-03-27T01:23:45"],
  "double": [true, "false", 1, "0", 5, "5", 2.5, "2.5E0", "2011-03-27", "2011-03-27T01:23:45"],
  "date": [true, "false", 1, "0", 5, "5", 2.5, "2.5E0", "2011-03-27", "2011-03-27T01:23:45"]
}

My implementation currently results in the following (although I don't necessarily agree with all of these conversions):

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
[ xsd:boolean "true"^^xsd:boolean,
              "false"^^xsd:boolean,
              "5"^^xsd:boolean,
              "2.5"^^xsd:boolean,
              "2.5E0"^^xsd:boolean,
              "2011-03-27"^^xsd:boolean,
              "2011-03-27T01:23:45"^^xsd:boolean;
  xsd:integer "true"^^xsd:boolean,
              "false"^^xsd:integer,
              "1"^^xsd:integer,
              "0"^^xsd:integer,
              "5"^^xsd:integer,
              "2"^^xsd:integer,
              "2.5E0"^^xsd:integer,
              "2011-03-27"^^xsd:integer,
              "2011-03-27T01:23:45"^^xsd:integer;
  xsd:double "true"^^xsd:double,
              "false"^^xsd:double,
              "1.0E0"^^xsd:double,
              "0"^^xsd:double,
              "5.0E0"^^xsd:double,
              "2.5E0"^^xsd:double;
  xsd:date    "true"^^xsd:boolean,
              "false"^^xsd:date,
              "1"^^xsd:date,
              "0"^^xsd:date,
              "5"^^xsd:date,
              "2.5"^^xsd:date,
              "2.5E0"^^xsd:date,
              "2011-03-27"^^xsd:date,
              "2011-03-27T01:23:45"^^xsd:date
] .

We could also only perform coercion when the lexical form of the representation matches the XSD definition, although this would be at odds with use in RDF parses, such as Turtle. We currently say that native representations, whether coerced or not, remain in their original form, although xsd:double currently contradicts that, always coercing any value to an @value representation using "1.16E"

When compacting, when can data-typed @value representations be turned into native form? One possible solution would be to convert anything to native form where the lexical representation in @value matches that of the associated XSD definition.

Is 1.16E preserving of 64-bit doubles? In my Ruby implementation it produces rounding errors:

"%1.16E" % 5.2 => "5.2000000000000002E+00" 
"%1.16E" % 5.3 => "5.2999999999999998E+00" 

%1.15E does not result in rounding errors. It would be useful for others to check their implementations.

Gregg

[1] https://github.com/json-ld/json-ld.org/issues/87
[2] https://github.com/json-ld/json-ld.org/issues/81

Received on Tuesday, 27 March 2012 15:54:16 UTC