Issue 391: support for collections

[jeswr]

Closes #391

• See this document rendered online here

[jeswr]

Marking as draft whilst cleaning up the HTML to ask the following questions:

• Should we allow sh:NodeShapes to be the subject of sh:memberShape? I've currently disallowed this.
• Is there a normative reference for well-formed lists that I should point towards

[HolgerKnublauch]

I would allow it for NodeShapes too. Your definition already uses the term value node, and for node shapes that just means the focus node. Are you hesitating because it may require additional test cases?

And on RDF lists, why not just reference SHACL Lists within the same document?

[TallTed]

tiny

[ajnelson-nist]

I won't log a "Request Changes" review in case that mucks up process (especially as a non-Editor on the doc), but I do urge working through Resolving all of my comment threads except maybe the first one that I said was non-blocking.

Also, thanks for updating the SHACL-SHACL shapes.

[jeswr]

@ajnelson-nist Thanks for reviewing the tests - I've gone back and put together simpler test cases to improve readability. I had used copilot to quickly put together the tests whilst the PR was in draft. They are now human crafted and checked.

I would allow it for NodeShapes too. Your definition already uses the term value node, and for node shapes that just means the focus node. Are you hesitating because it may require additional test cases?

This is now allowed; I was struggling to think of a case where it'd be used in practise - but I can think of a few including sh:targetObjectsOf ex:speakerOrder.

And on RDF lists, why not just reference SHACL Lists within the same document?

Good point - now using SHACL lists; I'd forgotten they were defined in the doc.

[jeswr]

@TallTed I think I've addressed all of your requested changes - could you please update your review so this isn't blocked from merging.

@ajnelson-nist Could I ask you to confirm your approval with the current state of this PR.

[ajnelson-nist]

This target isn't among the expected test results, but looks like it should trigger a violation.

[jeswr]

This is a valid SHACL list (it is just rdf:nil) so I expect this to pass.

I can see cases where you'd want to make sure the list does have have some elements - I've raised #414 to propose sh:minCollectionLength and sh:maxCollectionLength as constraints

[ajnelson-nist]

_:b3 isn't among the data.

[jeswr]

That is intended. It should raise a violation because a blank node with no properties is an invalid list.

[ajnelson-nist]

@ajnelson-nist Could I ask you to confirm your approval with the current state of this PR.

Overall, the progress is good. My (soft-)blockers are:

• There's a validation illustration that I think needs an update.
• shacl12-test-suite/tests/core/node/memberShape-001.ttl needs a data fix.
• Another test technically works, but for could use a nit-level data fix.

Again, I won't push the "Request Changes" button in case that mucks up process.

[ajnelson-nist]

While looking over SHACL-SHACL updates today, I noticed there's a live use case for this PR within SHACL-SHACL.

#160 / #395 expanded sh:datatype and sh:class to take lists that otherwise need to behave like a singleton value.

It's a bit debatably scope-creep, but I think sh:memberShape could be used on the (blank-node) property shapes on sh:ShapeShape for sh:class and sh:property. E.g.,

        ] ;
        sh:property [
                sh:path sh:class ;
-                sh:nodeKind sh:IRI ;            # class-nodeKind
+                sh:or (
+                        [ sh:nodeKind sh:IRI ]
+                        [ sh:memberShape [ sh:nodeKind sh:IRI ] ]
+                ) ;            # class-nodeKind
         ] ;
        sh:property [
                sh:path sh:closed ;

Though, thinking about the case (possibly pathologically?) of an IRI-identified rdf:List, I'm seeing some vision of a list that could evade SHACL-SHACL's syntax review.

ex:Foo
        a rdfs:Class ;
        .

ex:ExampleShape
        sh:class ex:ExampleList ;
        .

ex:ExampleList
        rdf:first "foo" ;
        rdf:rest (
                ex:Foo
        )
        .

All the above would also apply for datatype-nodeKind.

I'm fine with this being broken out into a separate issue, not blocking this PR, examining 391 and 160 thrown against one another.

[TallTed]

lgtm