Re: Understanding of JSON-LD values

On 13 June 2013 15:42, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Thursday, June 13, 2013 2:29 AM, Peter Ansell wrote:
>
> > 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.
>
> We support lossless round-tripping of JSON-LD to RDF and back.. but in
> that case it won't be idiomatic JSON. All you have to do is to set the use
> native types flag to false when serializing RDF as JSON-LD -- and that's
> the default value by the way.
>
>
The reason that people are continuing to discuss this is that there will be
issues round-tripping to RDF in the general case and people should at least
be aware of this. Some people who I have talked to are under the impression
that JSON-LD has the same compatibility with XMLSchema as the existing RDF
serialisations without corner cases (in this case the corner case is the
recommended use for the JSON audience). That there is the possibility of
round-tripping in the non-idiomatic-JSON case, doesn't fulfill the criteria
for lossless round-tripping.

>
>
> > 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
>
> No, the difference is that there already exist JSON parsers for virtually
> every programming language. That's not the case for N3 and Turtle. The
> parsers that are being/have been built for that N3 and Turtle are
> being/have been built exactly for that purpose. I think the majority of the
> group just tries to ignore that fact. We are not starting at a clean slate.
> We have developed JSON-LD by considering the current JSON ecosystem. We
> started with implementations. We had a test suite from the very beginning.
> The specification was a result of our experiences.
>
>
The existence of a JSON parser does not imply that people can directly use
JSON-LD. They may be able to create JSON-LD but they would then have to
implement the JSON-LD parser spec to be able to parse arbitrary JSON-LD
documents. Without a specific JSON-LD parser implementation the JSON parser
would only be an advantage if all users send documents in a particular
profile of JSON-LD, (and they must reference a particular @context in the
case of Web Payments), which will encourage the current inefficient
practice of creating data serialisations to match specific APIs rather than
programming for reuse and longevity using only the RDF Abstract Model.

By comparison, Turtle is a much older specification, although there have
been a few minor changes once it started on the standardisation track.
Turtle parsers are actually available in a range of languages, including
Javascript, in contrast to your statement. In addition, Turtle is defined
directly on a shared abstract model, where JSON-LD has its own completely
unique abstract model.

What is the downside to parsers being written for a specific format btw?

At the risk of angering the JSON gods, the RDF/XML specification can be
parsed with existing XML parsers which have been implemented for a wide
range of languages. That doesn't mean it is more useful than any other RDF
serialisation that is compatible with the RDF Abstract Model.


>
> > 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?
>
> IMO no, if a user sets the use native types flag to true she expresses her
> intentions quite clear. Why should we ignore that?
>

It would be useful IMO not to transform a number if you knew that you could
not get it back again afterwards.

Peter