W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2013

Re: Updated JSON-LD spec to more closely align w/ RDF data model

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 10 Jul 2013 02:01:10 -0700
Message-ID: <51DD22D6.3010308@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: 'RDF WG' <public-rdf-wg@w3.org>

On 07/10/2013 12:24 AM, Markus Lanthaler wrote:
> On Wednesday, July 10, 2013 2:34 AM, Peter F. Patel-Schneider
>> Appendix A looks good, modulo an answer to my query about mixed types
>> for JSON numbers.
> Great. By your query about mixed types you mean the mapping to xsd:integer and xsd:double depending on the fractional part, right?

>> Appendix C should mention the new generalized RDF datasets, I think,
>> but the other changes look OK.
> It does:
>     In JSON-LD properties can be IRIs or blank nodes whereas in RDF
>     properties (predicates) have to be IRIs. This means that JSON-LD
>     serializes *generalized RDF Datasets*.
> with "generalized RDF Datasets" being a link to the definition in RDF Concepts. Do you think we need to add another sentence?

Oops, I didn't read far enough.

I was commenting about parts of the first paragraph in Appendix C that do not 
appear to have been adjusted to account for generalized RDF datasets.

> Could you please propose one.

I would like to see the first part of Appendix C adjusted to match Appendix A, 
something like:

JSON-LD is a concrete RDF syntax 
<http://www.w3.org/TR/rdf11-concepts/#dfn-concrete-rdf-syntax> as described in 
[RDF11-CONCEPTS <http://json-ld.org/spec/latest/json-ld/#bib-RDF11-CONCEPTS>]. 
Hence, a JSON-LD document is an RDF document and a JSON document and 
correspondingly represents an instance of an extended RDF data model, namely 
generalized RDF datasets [link]. The extension to the RDF data model is:

  * In JSON-LD properties
    <http://json-ld.org/spec/latest/json-ld/#dfn-property> can be IRIs
    <http://json-ld.org/spec/latest/json-ld/#dfn-iri> or blank nodes
    <http://json-ld.org/spec/latest/json-ld/#dfn-blank-node> whereas in
    properties (predicates) in RDF datasets have to be IRIs

Summarized, these differences mean that JSON-LD is capable of serializing any 
RDF graph or dataset and most, but not all, JSON-LD documents can be directly 
interpreted as RDF datasets. It is possible to work around this restriction, 
when interpreting JSON-LD as RDF, by transforming blank nodes 
<http://json-ld.org/spec/latest/json-ld/#dfn-blank-node> used as properties 
<http://json-ld.org/spec/latest/json-ld/#dfn-property> to IRIs 
<http://json-ld.org/spec/latest/json-ld/#dfn-iri>, minting new "Skolem IRIs" 
as per Replacing Blank Nodes with IRIs 
<http://www.w3.org/TR/rdf11-concepts/#section-skolemization> of 
[RDF11-CONCEPTS <http://json-ld.org/spec/latest/json-ld/#bib-RDF11-CONCEPTS>]. 
The normative algorithms for interpreting JSON-LD as RDF and serializing RDF 
as JSON-LD are specified in the JSON-LD Processing Algorithms and API 
specification [JSON-LD-API 

>> Given the issues with respect to numbers in JSON, I would change
>> http://json-ld.org/spec/latest/json-ld/#dfn-number, but what to change
>> it to depends on just what JSON numbers are supposed to be. Certainly mixed
>> integers and double floats is not a numeric type in any programming language
>> that I am familiar with.
> Please don't forget that it is a serialization format and not a in-memory data model. Maybe we should make it clearer that the representation of numbers is similar to that used in most programming languages!?

Argh, no!  That's not helpful at all.   JSON numbers aren't like numbers in 
most programming languages.  (In fact, JSON numbers aren't like numbers in any 
programming language - JSON numbers are just sequences of Unicode characters, 
apparently with no particular meaning attached to them, but that's a different 
story.)  Let's please not repeat the problems with RFC4627.

Part of the point here is precisely that JSON is a serialization format, so 
one does need to figure out what it is a serialization of.
>> Similarly, JSON strings don't really represent (just) Unicode characters, but
>> the distinctions here might be too obtruse for even this document.
> Yeah, please don't let's start about talking unpaired surrogates here. I haven't ever seen this being a problem in practice so I consider this mostly a theoretical problem.

You are now in W3C land, where some people (rightly) care a lot about issues 
like this.  I'm a bit surprised that no one has commented about this issue.
> --
> Markus Lanthaler
> @markuslanthaler
Received on Wednesday, 10 July 2013 09:01:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:30 UTC