- From: Andy Seaborne <andy@apache.org>
- Date: Thu, 04 Jul 2013 12:25:54 +0100
- 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: http://lists.w3.org/Archives/Public/spec-prod/2005JanMar/0001.html ) > > > > -- > Markus Lanthaler > @markuslanthaler > >
Received on Thursday, 4 July 2013 11:26:24 UTC