Turtle shortcut for list as a triple term

[franconi]

We could introduce a Turtle shortcut to write a list as a RDF term: e.g., (:a (:c :d) :e) would expand to the RDF term:

<<(a cons 
   <<(<<(c cons 
         <<(d cons 
            nil)>> 
        )>> cons 
      <<(e cons 
         nil)>> 
     )>> 
  )>> 

corresponding to the classical cons tree structure:

ℂ   ➡︎  a
⬇︎
ℂ   ➡︎  ℂ ➡︎ c
⬇︎      ⬇︎
ℂ ➡︎ e  ℂ ➡︎ d
⬇︎      ⬇︎
NIL    NIL

So lists would be RDF terms in both Turtle and N-Triple, and their N-Triple version would be using the reserved IRIs rdfx:cons, rdfx:list, rdfx:nil, with the following axiomatic triples:

rdfx:cons rdfs:range rdfx:list.
rdfx:nil a rdfx:list.

Observe that a triple term using only rdfx:cons properties would always represent a legal list, assuming that each object in the triple term is either a triple term or equal to the rdfx:nil IRI.

[niklasl]

The idea is intriguing; though the nested list example relies on triples as subjects. Also, it's still not possible to have literals in such lists, unless we allow literals as subjects. (Or, in either case, use indirection with rdf:value.)

(Another option, way out of scope for the WG, could be adding pairs as a kind of object term next to triples and literals.)

(See also "define lists using just triple terms" in my old musing.)

[franconi]

Correct observation. In any case, I believe that this is not in the scope of the WG, but just an application, I guess.

[hartig]

I don't think that, from a query and update perspective, representing lists in this way is so much better than RDF Collections. In fact, for RDF collections of arbitrary length, it is at least possible to query them using the property paths feature of SPARQL (e.g., to enumerate all list elements). For nested triple terms we don't (yet) have the same kind of functionality in SPARQL (e.g., to recursively dive into a nested triple term to an arbitrary, non-fixed depth).

Perhaps that's a good point to advertise again our SPARQL-CDTs approach ;-)
(but also that is something beyond the scope of the WG)

[pchampin]

Correct observation. In any case, I believe that this is not in the scope of the WG, but just an application, I guess.

I concur, and accordingly, add the "proposed closing" label