Clear out tree:shape definition

[sandervd]

The range of tree:shape is set to shacl:NodeShape. However if a stream contains is mixed (multiple datatypes), this can cause some confusion:
Is it allowed to link to a SHACL shape with multiple NodeShapes? Or should multiple tree:shape references be added, practically splitting out the SHACL file?

[pietercolpaert]

Cardinality is undefined, so yes, it can have multiple node shapes. By default in RDF, this means there will be an AND between these nodeshapes: each member will have to validate all nodeshapes.

If there needs to be an OR, can’t you use this: https://www.w3.org/TR/shacl/#OrConstraintComponent ?

Mind that my knowledge of SHACL is a bit shaky

[sandervd]

As an alternative to the current implementation I would suggest to drop the range of tree:shape, and instead define tree:shape as a subproperty of sh:shapesGraph.

[pietercolpaert]

Revising what I said here: now that I fully dove into SHACL, I believe just referring to a sh:NodeShape is the most clear. You can indeed use the logical components of SHACL to make choices there.

I’d even propose to make tree:shape refer to exactly one sh:NodeShape.

[pietercolpaert]

From the call of 2024-04-24:

2 separate pull requests to be prepared:

• Cardinality constraint to exactly 1, and maybe even include a note on why this is
• Possibility to have 2 extra properties: tree:validatedBy, which points to a shape that should not be used by the member extraction, and a term tree:shapeTopology, which should not be used by validators, but can be used for source selection and member extraction. When tree:shapeTopology is not defined, but tree:shape is, then it falls back to that shape.

[pietercolpaert]

The cardinality constraint on 1 has been merged into main.

The possibility of having other type of shape links is still being debated based on #113: it currently mainly feels like a fix for a member extraction algorithm that doesn’t do what we want sometimes.