Re: Understanding of JSON-LD values

On 13 June 2013 07:49, Sven R.Kunze <sven.kunze@informatik.tu-chemnitz.de>wrote:

> Good evening everybody,
>
> in a former discussion, I mentioned that the purpose of “native literals”
> in the JSON-LD data model is not clear to me. And it still is not.
>
> Markus wrote:
> “JSON-LD has e.g. native numbers and (probably more interesting) lists. In
> RDF everything is a opaque string that can only be interpreted, i.e.,
> converted to a number in your programming language, if you understand the
> data type. So to speak, JSON-LD has a built-in data type for numbers.”
>
> So, what is the advantage of that? Shouldn’t every RDF graph lib provide a
> way to parse the literals with a datatype native to the programming
> language one uses?
>
>
> Of one drawback, I could easily think of: it’s confusing as it mixes up
> serialization and abstract model. What is so bad of having only *ONE* value
> for the number 42 instead of two?
>
> The standard RDF data model only have *ONE* value for it whereas the
> JSON-LD model suggests *TWO*, namely the ‘native value’ and the
> datayped-string value. Correct me, when I get something wrong.
>
> Another question that arises when having two different 42 (is that even
> possible?) is the fact of how to work with them. Are they considered equal
> (in the mathematical sense)? Can I add/substract/... “42”^^xsd:integer and
> 42? What are the results: 84 or “84”^^xsd:integer?
>
> In order to refer to Markus’ statement:
> “In RDF everything is a opaque string that can ....” <<< that is not quite
> true as JSON data itself is only an opaque string, too, that only a JSON
> parser is able to understand.
>
> Other example: in N3, you can write false as a shortcut
> for “false”^^xsd:boolean.
>
>
> Having said this, I do not quite understand why there is a need for
> such ‘native values’ in the data model when it’s just a serialization issue
> which on its own is perfectly valid as is simplifies a lot. But on the data
> model side, it’s more than questionable.
>
> In order to state it more clearly:
>
>    1. When both a ‘native value’ and a ‘typed-literal value’ refer to the
>    very same entity, I do not see the purpose of introducing ‘native values’
>    as syntactic sugar belongs to the syntax part and not to the abstract model
>    part.
>    2. When they don’t, the above mentioned questions should be answered
>    clearly within the spec.
>
>
>
>
>
>From my understanding, the JSON-LD-API spec [1] (as they are intentionally
not normatively referring to either RDF or XMLSchema in the JSON-LD spec to
reduce the learning curve for JSON-only developers) provides RDF
transformation algorithms that are controlled by the useNativeTypes setting
[2] (which is not a field on JsonLdOptions?? [3]) to determine whether to
migrate numeric and boolean datatypes between XMLSchema and JSON Native
datatypes when converting to RDF.

There should be no issues with the basic integer datatype that has the same
value space. The issues that I have been enquiring about recently were in
the double datatype. The reason that they are not syntactic sugar, from my
understanding, are that the value spaces are not equivalent. Ie, you cannot
represent some XMLSchema double and decimal numbers in JSON Native.

The overarching goal of JSON-LD is to be completely compatible with
idiomatic JSON, and not RDF, so they must offer the ability for users to
use JSON Native types, even if that introduces round-tripping issues.
Although all RDF libraries will offer full support for the commonly used
XMLSchema datatypes, JSON-LD is focused on avoiding any dependencies on RDF
or XMLSchema libraries due to a feared backlask by JSON developers if they
do. JSON developers are notorious for their hatred of anything XML, and
(possibly by extension) RDF due to the historical link between RDF and
RDF/XML.

The difference with N3 and Turtle are that their native valuespaces are
based on XMLSchema datatypes, so there are no issues with conversion to RDF
Abstract Model for N3/Turtle/other RDF users who virtually universally are
using XMLSchema to represent numeric data internally and in their
serialisations

Would it be useful to add a note to RDF-2-JSON-LD transformers that they
MAY leave xsd:double values as non-native if they can determine that the
transformation would not be lossless, even if the useNativeTypes flag is
set to true?

Cheers,

Peter

[1] http://www.w3.org/TR/2013/WD-json-ld-api-20130516/#data-round-tripping
[2]
http://www.w3.org/TR/2013/WD-json-ld-api-20130516/#convert-from-rdf-algorithm
[3]
http://www.w3.org/TR/2013/WD-json-ld-api-20130516/#the-jsonldoptions-type