Convert also "partial" lists from RDF to JSON-LD

[lanthaler]

_This came up in a discussion with @afs:_

On Thursday, July 04, 2013 10:21 PM, Andy Seaborne wrote:

The set of all heads of well-formed lists can be found quite easily.

All lists have a common tail (rdf:nil). Just walk back up the list
checking nodes have exactly one rdf:first and one rdf:next triple.
This generates the list head.

You are of course right and the necessary changes to the algorithm should be quite small.

Currently a @list can never be the value of a rdf:first/rdf:rest. This kind of ensures that only "complete" lists are transformed to @list and that we don't produce lists of lists in JSON-LD.

An example might clarify what I mean. Currently we would never produce something like

{
  "@id": "http://example.com/",
  "rdf:first": "A",
  "rdf:rest": { "@list": [ "B", "C", "D" ] }
}

all the list bnodes would be preserved:

[
  {
    "@id": "http://example.com/",
    "rdf:first": "A",
    "rdf:rest": { "@id": "_"b0" }
  },
  {
     "@id": "_:b0",
     "rdf:first": "B"
     "rdf:rest": { "@id": "_:b1" }
  },
  ...
]

(edit: fixed second example)

Arguably changing that would result in a nicer result. This might also be a quite elegant solution for the OpenAnnotation people. I think we could threat this change as an algorithmic bug fix (meaning, no need for another LC).

Thoughts?

[niklasl]

I agree. I actually thought it was supposed to behave this way, so I'd certainly consider it a bug fix.

(Just a detail: in the second example (how it is currently), first object, you meant "rdf:rest": "_:b0", right?)

[lanthaler]

Yeah, you are right... stupid copy-paste error. I fixed the example.

[gkellogg]

The @id of the first object can't be "http://example.com/", surely? To be a list, the subject must be a BNode.

It also makes sense that @list can be the value of rdf:rest (and perhaps rdf:first, as well). The algorithm would find the list head at the first node having rdf:first/rest with only single well-formed values, as it does now; this should include those for which the subject is a non-well-formed value of an rdf:rest.

An example @afs and I were working on offline is more like the following:

Turtle:

@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://example/> .

:x :list _:a .

_:a rdf:first 1 .
_:a :additional "foo" .
_:a rdf:rest  _:b .

_:b rdf:first 2 .
_:b rdf:rest  _:c .

_:c rdf:first 3 .
_:c rdf:rest  rdf:nil .

JSON-LD:

{
  "@context": {...},
  "@id": "_:x",
  "list": {
    "additional": "foo",
    "rdf:first": 1,
    "rdf:rest: {"@list": [2, 3]}
  }

}

[lanthaler]

It also makes sense that @list can be the value of rdf:rest (and
perhaps rdf:first, as well). The algorithm would find the list head at

I haven't thought much about it yet but wouldn't allowing it in rdf:first mean that (without additional checks) you would end up creating list of lists? We currently keep a reference to the bnode-object that is then replaced with a @list-object. Doing that for rdf:first would mean that you could replace a bnode-reference in a list with a list.

the first node having rdf:first/rest with only single well-formed
values, as it does now; this should include those for which the subject
is a non-well-formed value of an rdf:rest.

An example @afs and I were working on offline is more like the
following:

Turtle:

@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://example/> .

:x :list _:a .

_:a rdf:first 1 .
_:a :additional "foo" .
_:a rdf:rest  _:b .

_:b rdf:first 2 .
_:b rdf:rest  _:c .

_:c rdf:first 3 .
_:c rdf:rest  rdf:nil .

JSON-LD:

{
  "@context": {...},
  "@id": "_:x",
  "list": {
    "additional": "foo",
    "rdf:first": 1,
    "rdf:rest: {"@list": [2, 3]}
  }
}

Yes, that's a consequence of allowing @list as value of rdf:rest and is what I meant when I referred to OpenAnnotation.

[lanthaler]

RESOLUTION: Adopt Markus' algorithmic change to convert partial lists from RDF to JSON-LD.

[lanthaler]

The from RDF algorithm has been updated to handle "partial" lists as well. This addresses an issue the OpenAnnotation CG encountered (cc'ed). The tests have been updated and some new ones have been added.

Unless I hear objections, I will therefore close this issue in 24 hours.