feat: better support for collections

[jeswr]

It would be nice to have the constraint sh:listOf that could be used as follows (i.e. used to state that the object should be a collection with contents satisfying given constraints):

	sh:property [
		sh:path ex:speakerOrder ;
		sh:listOf [
                  sh:nodeKind IRI ;
                ] ;
               sh:maxCount 1 
	] .

If not feasible to add to the core spec in 1.2 - then we may wish to still have shorthand in SHACL-C which gets expanded to something that looks like http://www.w3.org/ns/shacl-shacl#ListShape .

[ajnelson-nist]

It's possible to do this in SHACL 1.0. It relies on spelling with the internals of RDF List IRIs, though. It seems like a candidate for syntactic sugar.

If I understand what you were after, this would be the spelling of your example:

[]
    a sh:NodeShape ;
    sh:targetClass ex:Agenda ;
    sh:property [
        sh:path (
            ex:speakerOrder
            [ sh:zeroOrMorePath rdf:rest ]
            rdf:first
        ) ;
        sh:nodeKind sh:IRI ;
    ] ;
    sh:property [
        sh:path ex:speakerOrder ;
        sh:maxCount 1 ;
    ] ;
    .

I tried running that with a SHACL engine because I had a moment of doubt on if I was about to stub a toe on an rdf:nil case. Here is an example data graph. My understanding is consistent with the engine output that I got: ex:agenda-2 should raise a sh:Violation, but ex:agenda-1 should be fine.

ex:agenda-1
    a ex:Agenda ;
    ex:speakerOrder (
        ex:Alice
        ex:Bob
        ex:Charlie
    ) ;
    .

ex:agenda-2
    a ex:Agenda ;
    ex:speakerOrder (
        ex:Alice
        ex:Bob
        [ rdfs:label "Charlie" ]
    ) ;
    .

I think that little moment of doubt, times N for M SHACL users, could be an argument for this syntactic sugar. I haven't put energy into thinking of arguments against it yet.

[HolgerKnublauch]

Yeah, if enough people are using rdf:Lists then having core constraints makes sense. The alternative with rdf:first/rest paths is too error prone and geeky. I guess in addition to sh:listOf there could be sh:minListLength and sh:maxListLength. I would prefer a name such as sh:memberShape over sh:listOf, as it makes clear that the values are shapes.

FWIW I had included this variant into our own tosh namespace a few years ago:

tosh:MemberShapeConstraintComponent
  a sh:ConstraintComponent ;
  rdfs:comment "Can be used to specify constraints on the members of a given list, assuming that the given sh:property has rdf:Lists as values. A violation is reported for each member of the list that does not comply with the constraints specified by the given shape." ;
  rdfs:label "Member shape constraint component" ;
  sh:parameter tosh:MemberShapeConstraintComponent-memberShape ;
  sh:propertyValidator [
      a sh:SPARQLSelectValidator ;
      sh:message "List member  does not have the shape {$memberShape}" ;
      sh:prefixes <http://topbraid.org/tosh> ;
      sh:select """
		SELECT DISTINCT $this ?value ?failure ?member
		WHERE {
			$this $PATH ?value .
			?value rdf:rest*/rdf:first ?member .
			BIND (tosh:hasShape(?member, $memberShape) AS ?hasShape) .
			BIND (!bound(?hasShape) AS ?failure) .
			FILTER (?failure || !?hasShape) .
		}
""" ;
    ] ;
  sh:targetClass sh:PropertyShape ;
.
tosh:MemberShapeConstraintComponent-memberShape
  a sh:Parameter ;
  sh:path tosh:memberShape ;
  sh:class sh:Shape ;
  sh:description "The shape that the list members must have." ;
  sh:name "member shape" ;
.

[HolgerKnublauch]

FYI the preference of the process for SHACL Core is to finish the set of included features in a few weeks. Any ticket that is not assigned to anyone may get marked postponed. If anyone outside of the editors team feels strongly that this should be implemented, you are welcome to submit a PR.

The alternative here is to leave these use cases to another namespace and define the constraint components using SPARQL or node expressions.

[jeswr]

@HolgerKnublauch - just picking this up now. I note that in tosh the class is constrained to sh:Shape rather than sh:NodeShape - can I confirm that:

• This is intended behaviour
• The semantics of it is "If a NodeShape, validate each member against the NodeShape. If a property shape, evaluate each member against an open NodeShape with a single property constraint as given by the property shape"
• We want the same semantics to be applied in the sh:memberShape which I am currently writing a PR for.

I tried to follow the following link to tosh - given as an sh:prefix in the example above as http://topbraid.org/tosh - the link appears to be broken.

[HolgerKnublauch]

I am attaching a copy of the tosh namespace, which is bundled with our product but otherwise not online

tosh.ttl.txt

On the semantics, I think it would indeed be better to align this with sh:node semantics and have sh:NodeShape as the only allowed values. The case of pure property shapes feels rather rare and can easily be addressed with a fresh node shape that just has one property constraint.