Support for strongly/concretely typed rdf:List

[earcam]

Hello,

I would love to see support for strongly-typed rdf:Lists; have just created a Gist demonstrating valid SHACL shapes for rdf:List of Datatype and Class.

Apologies if I'm missing something, only just started playing with shacl-form, please advise if it's obvious how to form type-safe lists for R/W, or there's a workaround.

Thanks,
Caspar

[s-tittel]

Thanks for the detailed example and the accompanying Gist!

Supporting this is unfortunately more involved than adding another datatype or constraint. An rdf:List is represented as a chain of blank nodes connected through rdf:first and rdf:rest, ending in rdf:nil. In the supplied shapes, that structure is described indirectly using recursive node shapes, sh:or, sh:not, and sh:zeroOrMorePath.

shacl-form currently renders properties whose paths map directly to editable RDF predicates. It does not support repetition paths such as sh:zeroOrMorePath, nor does it have special handling for constructing and updating ordered rdf:first/rdf:rest chains. Supporting this properly would require dedicated list UI, ordered insertion and removal, special serialization, handling of empty lists, and support for both literal and resource members. Merely accepting the repetition path would therefore not be sufficient.

Where ordering is not essential, a simpler model is to use repeated predicates instead of an RDF collection. For example:

ex:alice
    do:nickName "Anny" ;
    do:pet ex:fido, ex:sparky .

These can be described with ordinary property shapes:

[
    sh:path do:nickName ;
    sh:datatype xsd:string
] .

[
    sh:path do:pet ;
    sh:class do:Pet
] .

shacl-form already represents these as repeatable fields, including nested node shapes where appropriate.

The important caveat is that repeated predicate values are unordered, so this workaround is only suitable when member order has no semantic significance. If ordering must be preserved, first-class RDF-list support would still be needed.

I think typed RDF-list support could be a valuable future enhancement, but we would first need to define a constrained, documented SHACL pattern to support rather than attempt to interpret every possible recursive formulation.

Thanks again for raising this and providing such a useful test case.