Re: XSD datatypes in JSON-LD (was: Re: Use of XSD namespace in RDF recommendations)

On 5 Sep 2012, at 13:28, Markus Lanthaler wrote:
>> What is the justification then for treating the JSON literal 5 as
>> "5"^^xsd:integer in toRDF, rather than as "5"^^xsd:double? The latter
>> seems to be the accurate translation.
> 
> I would certainly be fine with just translating all JSON numbers to
> xsd:double but what should we do with xsd:integer in fromRDF() then? Keep it
> as string? Or convert it to a JSON number? If we do that, and I think we
> should, we would "break" round-tripping as we effectively transalte from
> xsd:integer to xsd:double.

I haven't thought enough about these issues to be of much help here I'm afraid. At the risk of saying something that I may no longer believe tomorrow: Why not treat RDF xsd:integers as expanded values in fromRDF()? People can use compaction with a context that does type coercion to a number.

> Splitting JSON numbers into xsd:integer/xsd:double was kind of a compromise
> to have a lossless round-trip *most* of the time. It doesn't work perfectly
> though.

Well, yeah, but it also makes the whole thing quite unpredictable.

>> Another issue I suppose is that xsd:double contains the values NaN, INF
>> and -INF, which are not valid as JSON numbers and hence cannot be
>> round-tripped if native JSON numbers are used.
> 
> Exactly. Therefore, if conversion to a native number fails, we keep the
> value in expanded form.

Ah, ok. I suppose this is clause 3.7.1.2) in the fromRDF algorithm. It wasn't clear to me what exactly is meant by “If the conversion is successful”.

3.7.1 confuses me in general. What exactly does “value” refer to here? Is it supposed to say “object” rather than “value”?

Best,
Richard

Received on Wednesday, 5 September 2012 13:49:42 UTC