RE: Understanding of JSON-LD values

On 13 June 2013 15:42, Markus Lanthaler 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.

http://json-ld.org/spec/latest/json-ld-api/#data-round-tripping

The only way to avoid that would be to implement custom parsers which would be a prohibitive requirement IMO.


>>> 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.

That's a completely different matter and has nothing (or not much) to do with the number round-tripping. The way you would handle this currently is to flatten the JSON-LD document you receive to transform it to a deterministic shape. A much more powerful mechanism is framing (but we took that out of the spec when we brought JSON-LD into the RDF WG).


> 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,

Parsers are not available as part of the language but there are implementations in various languages - that's the difference I wanted to highlight. We do not do any parsing, the parsing is done/specified for JSON. 


> 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?

There's no downside per see but it would make no sense to ignore the gazillions of JSON parsers and instead require the implementation of custom parsers.


> 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.

No, but that actually backs up my point. It would have made no sense if RDF/XML required custom parsers to be written.


>>> 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.

Yeah, that's exactly the point of the use native types flag. If you however meant that it would be useful to be able to convert booleans but not numbers or just specific data types, then yes, you are right. Everyone is free to implement such a feature and provide an API for that. That's one of the reasons we didn't define a API for the to/from triples/quads conversion.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 13 June 2013 10:33:09 UTC