JSON-LD Syntax document MUST utilize the RDF definitions

[lanthaler]

_Feedback from Peter F. Patel-Schneider_

I state that the JSON-LD Syntax document MUST not only align with RDF but MUST
also utilize the RDF definitions (particularly from RDF concepts). The vague
promises in the document are wholly inadequate; the change needs to happen
well before last call, as it is a major change.

For example, LSON-LD MUST be stated as a way of writing down RDF graphs (with
perhaps a simple generalization, although if linked data does not allow bnode
properties then I see no reason to allow bnode properties in LSON-LD).
JSON-LD nodes MUST be stated to be RDF nodes. JSON-LD data values MUST be
stated to be RDF literals and mention both plain and datayped literals. JSON
blank nodes MUST be stated to be RDF blank nodes. All the JSON ordered
constructs allowed in JSON-LD MUST be stated to be insignificant and there
MUST be a test that tests this, or MUST have a translation into something in
RDF that is ordered, and this translation should be prominent in the
document. Examples MUST be stated to be RDF, not linked data.

In essence, for JSON-LD to progress in the RDF WG, it should align to RDF, not
linked data! There should be many more occurrences of "RDF" than "linked
data". Consider the first bit of section 3.1 - it should say RDF in every
numbered point, except, perhaps, the last.

[lanthaler]

_@iherman's reply:_

(My activity lead's hat put down)

Without going into details, I think this may go a bit too far. I do understand the wish of the JSON-LD editors to use terminologies and presentations that are closer to the target audience of this document, who are primarily Web developers accessing RDF/Linked Data through their familiar JSON environment and who, for good or bad reasons, have some aversion v.a.v. core RDF. I agree that things should be aligned but I think 'There should be many more occurrences of "RDF" than "linked data"' would lead to this document be ignored by many whom we like to attract as possible users.

I would wait for the outcome of the work that Manu and Richard have signed up for working out the details for such alignments.

I agree that this issue should be put behind us before going to official LC, though.

[lanthaler]

_@msporny's reply:_

On 10/19/2012 12:04 AM, Peter F. Patel-Schneider wrote:

The technical issues are not as problematic as I had thought.

Good to hear. :)

The presentation issues, however, are quite a bit worse that I had
thought would be the case by now. The draft of 16 Oct scarcely
mentions RDF. It restates a whole lot of the basic definitions of
RDF, and even in ways that obscure the relationship between JSON-LD
and RDF. The draft of 18 Oct appears to be somewhat better, but not
(yet) by much.

These changes were requested by Richard Cyganiak and made to the spec
text. He is also working on the RDF Concepts/JSON-LD alignment:

#157

I state that the JSON-LD Syntax document MUST not only align with RDF
but MUST also utilize the RDF definitions (particularly from RDF
concepts). The vague promises in the document are wholly
inadequate; the change needs to happen well before last call, as it
is a major change.

We're working on it (above). If you have specific changes, you should
log them in the issue above or have a lengthy discussion with Richard.
I'm also available to talk about it in detail. You are also invited to
join us on the JSON-LD telecon next week (or any other week) to discuss it:

http://json-ld.org/minutes/

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?

(with perhaps a simple generalization, although if linked data does
not allow bnode properties then I see no reason to allow bnode
properties in LSON-LD).

Could you point to a part of the current JSON-LD spec that asserts that
Linked Data does not allow blank-node properties? Why do you think it
would be a good feature of a language capable of round-tripping RDF to
not be able to express bnodes?

JSON-LD nodes MUST be stated to be RDF nodes. JSON-LD data values
MUST be stated to be RDF literals and mention both plain and datayped
literals. JSON blank nodes MUST be stated to be RDF blank nodes.

I believe that Richard is working on terminology alignment as we speak.

All the JSON ordered constructs allowed in JSON-LD MUST be stated to
be insignificant

What do you mean by "JSON ordered constructs"? Do you mean the concept
of the JSON 'array'? If so, we cover this in "Section 4.9: Sets and Lists".

and there MUST be a test that tests this

There are a number of tests for @set and @list. I added an issue to
ensure that list order is maintained when round-tripping to/from RDF:

#167

I note that we don't have one for ensuring that a set isn't ordered, but
how do you write that test?

or MUST have a translation into something in RDF that is ordered, and
this translation should be prominent in the document.

We support ordered arrays via @list. We support unordered sets via @set.
We support round-tripping of both to and from RDF. All of this is
covered in "Section 4.9: Sets and Lists" of the JSON-LD Syntax spec and
all algorithms that could touch these data structures in the JSON-LD API.

Examples MUST be stated to be RDF, not linked data.

Which examples? How do we state that an example is RDF (since RDF is
just a data model)?

In essence, for JSON-LD to progress in the RDF WG, it should align to
RDF, not linked data!

Could you re-state this in a way that is actionable?

There should be many more occurrences of "RDF" than "linked data".

Number of times 'RDF' is mentioned in the spec: 59
Number of times 'linked data' is mentioned : 30

Although, this is a bad metric for any spec, imho.

Consider the first bit of section 3.1 - it should say RDF in every
numbered point, except, perhaps, the last.

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.

[lanthaler]

_More from Peter 1, 2:_

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.

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

(with perhaps a simple generalization, although if linked data does
not allow bnode properties then I see no reason to allow bnode
properties in LSON-LD).
Could you point to a part of the current JSON-LD spec that asserts that
Linked Data does not allow blank-node properties? Why do you think it
would be a good feature of a language capable of round-tripping RDF to
not be able to express bnodes?

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

JSON-LD nodes MUST be stated to be RDF nodes. JSON-LD data values
MUST be stated to be RDF literals and mention both plain and datayped
literals. JSON blank nodes MUST be stated to be RDF blank nodes.
I believe that Richard is working on terminology alignment as we speak.

All the JSON ordered constructs allowed in JSON-LD MUST be stated to
be insignificant
What do you mean by "JSON ordered constructs"? Do you mean the concept
of the JSON 'array'?

Yes.

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.

and there MUST be a test that tests this
There are a number of tests for @set and @list. I added an issue to
ensure that list order is maintained when round-tripping to/from RDF:

#167

I note that we don't have one for ensuring that a set isn't ordered, but
how do you write that test?

You have two JSON-LD document that use arrays and that have different
ordering, and you state that they encode the same RDF graph.

or MUST have a translation into something in RDF that is ordered, and
this translation should be prominent in the document.
We support ordered arrays via @list. We support unordered sets via @set.
We support round-tripping of both to and from RDF. All of this is
covered in "Section 4.9: Sets and Lists" of the JSON-LD Syntax spec and
all algorithms that could touch these data structures in the JSON-LD API.

Again, there are arrays in other places in JSON-LD. In particular they are
used for datasets. Order cannot be significant there.

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.

How do we state that an example is RDF (since RDF is
just a data model)?
Huh? You just say that this is an RDF graph.

In essence, for JSON-LD to progress in the RDF WG, it should align to
RDF, not linked data!
Could you re-state this in a way that is actionable?

See my other messages.

There should be many more occurrences of "RDF" than "linked data".
Number of times 'RDF' is mentioned in the spec: 59
Number of times 'linked data' is mentioned : 30

Yeah, sorry. I used string quotes as a shorthand, when I should have said
something like, references to RDF notions.

Although, this is a bad metric for any spec, imho.

Consider the first bit of section 3.1 - it should say RDF in every
numbered point, except, perhaps, the last.
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.

-- manu

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.

---

Here is a particular example.

The JSON-LD syntax doc says

A node
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#dfn-node
having an outgoing edge /must/ be an IRI
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#dfn-iri
or Blank Node
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#dfn-blank_node.

This is not about RDF in a strong way. It instead sort of mirrors the idea
that the subject of an RDF triple must be an IRI or a Blank node.

Being about RDF in a strong way would instead defer to the definitions in RDF
concepts.

[lanthaler]

_My reply:_

All the JSON ordered constructs allowed in JSON-LD MUST be stated to
be insignificant
What do you mean by "JSON ordered constructs"? Do you mean the
concept
of the JSON 'array'?

Yes.

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.

We already state at the beginning (section 1.2) that

"In JSON, an array is an ordered sequence of zero or more values. An array is represented as square brackets surrounding zero or more values that are separated by commas. 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)."

Does that address your concern?

and there MUST be a test that tests this
There are a number of tests for @set and @list. I added an issue to
ensure that list order is maintained when round-tripping to/from RDF:

#167

I note that we don't have one for ensuring that a set isn't ordered,
but
how do you write that test?

You have two JSON-LD document that use arrays and that have different
ordering, and you state that they encode the same RDF graph.

Aren't the tests toRdf-0012 and toRdf-0015 showing just that? The former ignores that array-order (by default), the latter serializes a list:

https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/toRdf-0012-in.jsonld
https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/toRdf-0012-out.nq

https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/toRdf-0013-in.jsonld
https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/toRdf-0013-out.nq

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.

Which figure are you referring to?

[msporny]

This issue is mostly blocked by the resolution to #157 - /cc @cygri

[lanthaler]

As announced on the mailing list, I'll close this issue now.