Re: Potential Formal Object from DERI over JSON-LD

On 10/20/2012 01:14 AM, Peter F. Patel-Schneider wrote:
>>> For example, LSON-LD MUST be stated as a way of writing down RDF
>>>  graphs
>> I was hoping that "Appendix B: Relationship to Other Linked Data 
>> Formats and Data Models" made this clear, does it not? If not,
>> what is the exact spec text you would like to see?
> 
> I want to see Section 3 defer to RDF concepts for all its base 
> definitions.

We could do this if Section 3.1 is moved, without much modification,
into RDF Concepts. RDF Concepts does not succinctly describe what the
data model is in such a simple way. We would most likely repeat the
section in a non-normative way in the JSON-LD spec to ease cognitive
load on the reader.

We don't want to make folks go off and read RDF Concepts in order to get
a basic understanding of the JSON-LD document. The target audience for
this spec; 1) doesn't care about the plumbing (ie: how RDF works), and
2) has a hard time piecing together W3C/IETF specs. That is not to
say that they're not capable of grasping the concepts... just that they
have far more important things to do with their time than read multiple
W3C specs in order to publish data.

To put this another way, Douglas Crockford could have just referred to
ECMA 262 3rd edition for the majority of the JSON spec, but he didn't do
that because the concept was more easily expressed by repackaging parts
of ECMA 262 in RFC 4627. We're using a similar approach for the JSON-LD
spec. We don't want people to have to go off and read RDF Concepts in
order to get a basic grasp of the spec... they should be able to just
read the JSON-LD Syntax spec to get a basic understanding of the language.

Having more acronyms (like RDF) sprinkled throughout the spec increases
the cognitive load on the reader.

> Then I want to see something that states in a normative section that
>  JSON-LD documents that have adequate context encode RDF graphs.

We already do this in "Appendix B.1 RDF":

"""
The RDF data model, as outlined in [RDF-CONCEPTS], is an abstract syntax
for representing a directed graph of information. JSON-LD is capable of
serializing any RDF graph, and performing full RDF to JSON-LD to RDF
round-tripping. A complete description of how JSON-LD maps to RDF and
algorithms detailing how one can convert from RDF to JSON-LD and from
JSON-LD to RDF are included in the JSON-LD API [JSON-LD-API] specification.
"""

> Huh?  I'm not requiring that JSON-LD not allow bnodes.  I'm requiring
> that JSON-LD not allow bnode properties.

I misunderstood you. Yes, we could make this restriction, although it
would be awkward to do so. We can't state that this is "illegal" because
it's a completely acceptable thing to do in JSON. We already warn people
not to do it in the spec:

"""
JSON-LD allows properties to be BNodes, while RDF does not. Expressing
properties as BNodes in JSON-LD only becomes an issue (and could raise
an exception) when it is transformed to RDF.
"""

It's only an issue when going to and from RDF. Seems silly to limit
JSON-LD just because RDF doesn't support this feature, especially since
JSON allows any literal as a property and the literal can be interpreted
in any way (in JSON).

To put this another way, you're suggesting that we state that you can't
use string literals and bnodes in JSON-LD just because RDF doesn't allow
it in the data model. I think it's better to say that you can do this in
JSON-LD, but it won't translate to the RDF data model. This has the
effect that any JSON document is a conforming JSON-LD document (which is
what we have right now). You can, however, do things in JSON that don't
translate to the JSON-LD data model or to the RDF data model... which is
just fine, imho.

>> If so, we cover this in "Section 4.9: Sets and Lists".
> 
> Arrays can occur in lots of places in JSON documents, only some of 
> which are covered in 4.9, I think.

As Gregg pointed out, we explicitly state how to interpret JSON arrays
in the spec:

"""
While JSON-LD uses the same array representation as JSON, the collection
is unordered by default. While order is preserved in regular JSON
arrays, it is not in regular JSON-LD arrays unless specific markup is
provided (see 4.9 Sets and Lists).
"""

>>> Examples MUST be stated to be RDF, not linked data.
>> Which examples?
> 
> Well, for example, the figure that was in the previous version of the
> document.

Are you stating that this:

"Figure 1: An example of a JSON-LD graph."

should state this?

"Figure 1: An example of an RDF graph."

>> We're going around in circles. That's where we started two years 
>> ago. Then we went to Linked Data. Then we went to the JSON-LD data 
>> model (after input from the RDF WG). Now you're asking us to go 
>> back to RDF in that section. I'd like the RDF WG group to give us 
>> clear direction on this, taking into account all of the /many/ 
>> discussions we've had on this point.
>> 
> Well maybe the spec is going around in circles.  My view is that I'm
>  calling in the marker in the previous version of the document about
>  using RDF concepts.  If that cycles back closer to something in an 
> old version, well then maybe the old versions were better than the 
> version that was sent to the RDF WG.

The spec is going around in circles because members of the RDF WG are
giving us conflicting requirements. Here's where we started out:

JSON-RDF conflating RDF with Linked Data. Kingsley (rightly so)
corrected this conflation, so JSON-RDF became JSON-LD. We had to define
what Linked Data was at that time - this process took 3 months, but we
finally figured it out and everybody seemed to be happy for the next
year of the spec's life.

A few months ago, RDF WG members (primarily Richard Cyganiak) asked us
to align JSON-LD with RDF Concepts. We agreed to do that, with the
caveat that we don't overly burden the people that don't care about RDF
(which is the primary audience for this spec). Richard is currently
authoring the section outlining how the JSON-LD model maps to RDF
Concepts. This is in an appendix where it rightfully belongs, IMHO.

Now we have Michael and you stating that JSON-LD's data model should be
RDF, even though it has been proven that JSON and JSON-LD's data model
is more expressive than RDF. We also clearly state how one round-trips
from JSON-LD to RDF and back, and some of the caveats involved in that
process. It is also clear that you don't have to round-trip to RDF and
back for JSON-LD to be useful in many cases.

I think what we need at this point is clear direction from the RDF WG in
the form of a resolution or two. Clearly we have conflicting opinions on
the matter and rather than continue to churn the JSON-LD Syntax spec via
the "Go Fetch Me a Rock" change request process, we should figure out
exactly what the RDF WG wants and implement that.

I'm requesting that the chairs put aside considerable time during the
call this week to discuss this issue. Here are a few proposals that we
could discuss:

1. Align the JSON-LD data model with RDF Concepts in an Appendix (which
   we're already doing, but don't have a resolution for).
2. Add Section 3.1 in the JSON-LD Syntax document to the RDF Concepts
   document, re-state it in JSON-LD Syntax in a non-normative way, and
   point to RDF Concepts for the normative text.
3. Restrict the JSON-LD data model to be exactly the RDF data model,
   which would have broad conformance ramifications (any JSON document
   would no longer constitute a valid JSON-LD documents).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
http://manu.sporny.org/2012/nuclear-rdf/

Received on Sunday, 21 October 2012 15:40:15 UTC