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

On Thursday, July 04, 2013 1:26 PM, Andy Seaborne wrote:
> 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. ".

OK. Does the rest of the RDF WG share that opinion? I know that at least
Richard disagreed.


> 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).

The algorithm currently doesn't support this as it would make it
considerably more complex to find *the* head of the list.


> >> 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 ...)

The reason it says "lists may represented using the @list keyword" in that
section is because the @list can be omitted if a @container is set the
context. This is shown in the example immediately following the one you
quoted.


> >> Suggestion: clarify as to whether there are other ways or not. E.g. "a
> >> list is represented using the @list keyword as follows:")

Yes, there are alternative forms as said above. Look at the next example.


> >> 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

I've opened ISSUE-276 to discuss it in our next telecon:
  https://github.com/json-ld/json-ld.org/issues/276


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 4 July 2013 16:47:12 UTC