Understanding of JSON-LD values

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:
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.
When they don’t, the above mentioned questions should be answered clearly within the spec.



Sven