TREE relations vs. SHACL constraint components

[bergos]

Is there a particular reason why the tree spec defines its own relations and doesn't use SHACL constraint components? I would see the following benefits:

• SHACL is already used for generated UIs, and that could be reused in case one wants to provide a UI to navigate a tree.
• The tree spec could become shorter as we don't need to define all the semantics for the comparisons.
• SHACL doesn't define geospatial constraint components at the moment. That could be done outside the SHACL spec, and more people would benefit from such a specification.

Drawback:

• It may take longer to add something to the SHACL spec if we identify any gaps.

[pietercolpaert]

I’m not sure how we would be able to do that to be honest. Could you mint an example of what that would look like?

We could also just refer to specific shacl components from the spec of course, but I’m not sure either where exactly

[bergos]

I've adapted example 2 of the specification to the proposed idea, keeping the AND logic of multiple tree relations. tree:Relation would become a subclass of sh:PropertyShape:

@prefix ex: <http://example.org/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix tree: <https://w3id.org/tree#>.

ex:Collection1 a tree:Collection;
  tree:member
    ex:Subject1,
    ex:Subject2;
  tree:view ex:Node1.

ex:Node1 a tree:Node;
  tree:relation
    ex:R1,
    ex:R2,
    ex:R3.

ex:R1 a tree:Relation;
  sh:minInclusive 3;
  sh:path ex:value;
  tree:node ex:Node3.

ex:R2 a tree:Relation;
  sh:maxExclusive 10;
  sh:path ex:value;
  tree:node ex:Node3;
  tree:remainingItems 7.

ex:R3 a tree:Relation;
  sh:minInclusive 10;
  sh:path ex:value;
  tree:node ex:Node4;
  tree:remainingItems 10.

ex:Subject1 a ex:Subject;
  ex:value 1;
  rdfs:label "Subject 1".

ex:Subject2 a ex:Subject;
  ex:value 2;
  rdfs:label "Subject 2".

We could also make tree:Relation a subclass of sh:NodeShape. That would allow to have multiple comparators in a single relation. That would require adapting the logic of how to search for a node a little bit. Depending on whether people use a single value/comparator to find the next node or more/all of the values, this could even simplify the logic.

@prefix ex: <http://example.org/>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix tree: <https://w3id.org/tree#>.

ex:R1 a tree:Relation;
  sh:property [
      sh:minInclusive 3;
      sh:path ex:value1
    ], [
      sh:minInclusive 30;
      sh:path ex:value2
    ];
  tree:node ex:Node3.

[pietercolpaert]

That’s a really interesting idea!

I wonder how complex this would become to implement: where do we stop supporting sh:NodeShape and PropertyShape features?

I think we could just have a special type of tree:Relation that could support this: the tree:ShapeRelation.

I’ll schedule this issue in the next call