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: Andy Seaborne <andy@apache.org>
Date: Thu, 04 Jul 2013 12:25:54 +0100
Message-ID: <51D55BC2.5010108@apache.org>
To: public-rdf-wg@w3.org
On 04/07/13 12:07, Markus Lanthaler wrote:
> On Thursday, July 04, 2013 12:41 PM, Andy Seaborne wrote:
>> On 03/07/13 22:38, Gregg Kellogg wrote:
>>> I don't consider JSON-LD lists as being conceptually any different
>> that Turtle Lists; these are artifacts of the serialization, and not
>> the underlying data model.
>> Are all JSON-LD lists transformed to RDF lists by the
>> json-ld-api/#list-to-rdf-conversion?
> Yes.. but not all RDF lists are converted to JSON-LD lists. Only well-formed
> lists that are referenced exactly once.

That does not violate "A graph in JSON-LD should be a generalized RDF 
graph. ".

Personally, don't care much about the appearance of non-well-formed
lists.  The same occurs in Turtle pretty printing.

If a well-formed list-as-value, which is what Turtle-syntax lists are, 
get converted and there is no-loss of triples when round-tripping, no 
problem. The encoding of list elements outside the Turtle-syntax lists 
may not be beautiful - and that's the current situation with Turtle anyway.

[[ Non-well-formed lists have been a "nuisance" to me for a while 
(pretty printing Turtle, algorthms in SPARQL).  ]]

As the tail of a list is a list in its own right, the discussion about 
addition triples on the first element "just" means the first element 
needs encoding differently - the rest of the list is a @list isn't it (I 
have not checked the algorithm does this).

>> It's not clear -- it says "a list
>> may be represented using the @list keyword as follows:" -- not a RFC-
>> MAY but only a "may" nevertheless).
> Where's that statement?

"6.11 Sets and Lists"

and I got to that section when looking things up for this discussion so 
it came quite naturally (to me ...)

>> Suggestion: clarify as to whether there are other ways or not. E.g. "a
>> list is represented using the @list keyword as follows:")
>> The problem is about syntax and which data model is which.
>> This confusion is manifest by the fact that the documents are split
>> Serialization / Algorithms where the document entitles "serialization"
>> includes an appendix on "Data Model".
>> A separate document on "Data Model" would have been good.  Making that
>> it not-an-appendix, but still at the end of the document, might help.
> Most of our appendixes are normative. I would be fine with turning them (or
> even all) into normal sections.

(digressing... "normative appendix", except references, seems a bit of a 
contradiction in terms ... but it seems this is not new:


> --
> Markus Lanthaler
> @markuslanthaler
Received on Thursday, 4 July 2013 11:26:24 UTC

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