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

On Sunday, July 07, 2013 6:04 PM, Peter F. Patel-Schneider wrote:
> On 07/07/2013 08:43 AM, Markus Lanthaler wrote:
> >> JSON-LD is a serialization format for Linked Data based on JSON. It is
> >> therefore important to distinguish between the syntax, which is defined by
> >> JSON in [RFC4627], and the data model which is an extension of the RDF data
> >> model [RDF11-CONCEPTS].    *The precise details of how JSON-LD
> >> documents represent the RDF data model are given in Appendix C.*
>
> > Wouldn't it be more precise to say "The precise details of how
> > JSON-LD extends the RDF data model are given in Appendix C"?
> 
> What are the extensions (over generalized RDF Datasets)?  In fact, the
> "extension" should be taken out of the preceeding sentence. (Yes, this
> requires generalized RDF datasets.)

Native lists, JSON numbers and booleans. As you already did, you can also argue that they aren't extensions. So maybe it's even better to say something like "The precise details of how JSON-LD relates to the RDF data model are given in Appendix C"!?


> >> To ease understanding for developers unfamiliar with
> >> the RDF model, the following *informative* summary is provided:
> > Could live with that "informative" even though I would prefer to
> leave it out.
> 
> My view is that there needs to be a clear distinction between what is
> normative and what isn't.   Simply leaving out "normative" isn't
> adequately clear in this case, as far as I am concerned.

We use RFC2119 keywords in the description so I think it has to be normative unless we remove them.


> >> - A JSON-LD value is a string *(which is a shorthand for a typed value with
> >>     type xsd:string)*, a number *(with integral numbers being shorthand for
> >>     typed values with type xsd:long and other numbers being shorthand for
> >>     typed values with type xsd:double)*, true or false *(which are shorthands
> >>     for typed values with type xsd:boolean)*, a typed value, or a
> >>     language-tagged string.
> > OK.. it's xsd:integer not xsd:long though
> 
> Really? Arbiitrarily big?

Yes


> Personally I would prefer xsd:integer, but I thought that the idea was
> to reflect the JSON (although JSON really only has double-precision
> floating point).

No, JSON doesn't impose any restrictions on numbers. It is ECMAScript which uses doubles for JSON numbers.


> >> - A typed value consists of a value, which is a string, and a type, which is
> >>     an IRI.  *Most types in typed values are XML Schema 1.1 Datatypes
> >>     [pointer to document].*
> > I would really prefer to leave this out.
> 
> Why?

Because it doesn't add any value. RDF-aware readers know that already, others would probably get confused why *XML* Schema is used in a JSON spec and reading the document wouldn't make that much clearer. 


> >> - A list is an sequence of zero or more IRIs, blank nodes, and JSON-LD
> >>     values.  *JSON-LD lists are shorthands for RDF list structures
> >>     [informative pointer to RDF Semantics D.3?].*
>
> > If really necessary I could live with this but would prefer to not
> > state this here but perhaps mention it in Appendix C. I would like to
> > hear more opinions. Richard disagreed and I think Manu wouldn't be too
> > happy this either.
> 
> My (second-choice) view is that this appendix should be an informative way of

Which appendix do you mean? Appendix A Data Model or appendix C?

> showing that JSON-LD *is* RDF, without going into any of the low-level
> details.   Thus there should be at least a gloss on how all the bits
> and pieces of JSON-LD *are* RDF, particularly the bits that look as if they
> are different from RDF.

That's what I intended to do in appendix C. We would just have to say that a JSON-LD list corresponds to a rdf:List instead of talking about differences e.g.

Will you be able to join the JSON-LD telecon tomorrow? I would really like to try to resolve this issue this week.


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 8 July 2013 19:14:24 UTC