Support for logical constraints used with NodeShape

[tpluscode]

@vid, I've been thinking about ways to handle sh:or, sh:and, and sh:xone being properties of sh:NodeShape

• combine all properties

The first implementation could be the naively simple merge we discussed, where all nested sh:property are combined into the top shape. It could enough to have the end user to figure out the right combination of values which form a conforming graph. For example, the shape below would simply result in all ex:lastName, ex:firstName and ex:givenName rendered next to each other.

ex:OrConstraintExampleShape
   a sh:NodeShape ;
   sh:property [ sh:path ex:lastName ] ;
   sh:or (
      [
         sh:path ex:firstName ;
         sh:minCount 1 ;
      ]
      [
         sh:path ex:givenName ;
         sh:minCount 1 ;
      ]
   ) .

• reconcile overlapping properties

A more complex case is when properties would appear multiple times in separate shapes of a logical constraints. The spec shows an example of "inheritance", where multiple node shapes independently provide constraints which apply to one predicate

ex:SuperShape
   a sh:NodeShape ;
      sh:property [
         sh:path ex:property ;
         sh:minCount 1 ;
   ] .

ex:ExampleAndShape
   a sh:NodeShape ;
   sh:and (
      ex:SuperShape
      [
         sh:path ex:property ;
         sh:maxCount 1 ;
      ]
   ) .

This would require merging all constraints and rendering as only one editor

• handle conflicting groups

Finally, the most advanced feature could actually recognise groups of properties and help the user provide valid input by applying the constraints. Not sure yet what that would mean. Seen below, all child shapes of sh:xone could be actually offered in the UI so that not all properties are shown simultaneously. This begs the question what to do with the actual objects of said properties. Say, if ex:fullName is entered and ex:firstName also has a value, the graph would be invalid with the latter invisible in the UI. Not really user-friendly. On the other hand, the value of ex:firstName should not be cleared right away either. It could be made [disabled] but deciding whether to do so or not could be complicated to determine in some cases, especially if again same property appears in multiple exclusive sets.

ex:XoneConstraintExampleShape
   a sh:NodeShape ;
   sh:xone (
      [
         sh:property [
            sh:path ex:fullName ;
            sh:minCount 1 ;
         ]
      ]
      [
         sh:property [
            sh:path ex:firstName ;
            sh:minCount 1 ;
         ] ;
         sh:property [
            sh:path ex:lastName ;
            sh:minCount 1 ;
         ]
      ]
   ) .