shapes-ISSUE-133 (syntax): syntax simplification and regularization [SHACL - Core]

shapes-ISSUE-133 (syntax): syntax simplification and regularization [SHACL - Core]

http://www.w3.org/2014/data-shapes/track/issues/133

Raised by: Peter Patel-Schneider
On product: SHACL - Core

The current SHACL syntax has user-visible syntactic categories and
vocabulary for
- shapes (sh:Shape);
- scopes (sh:Scope), including property scopes (sh:PropertyScope), inverse
property scopes (sh:InversePropertyScope), all subjects scopes
(sh:AllSubjectsScope), and all objects scope (sh:AllObjectsScope);
- constraints (sh:Constraint), including node constraints
(sh:NodeConstraint) linked from shapes via sh:constraint,
property constraints (sh:PropertyConstraint) linked from shapes via
sh:property, and inverse property constraints (sh:InversePropertyConstraint)
linked from shapes via sh:inverseProperty.

This is a lot of machinery for a not-very-complex language.  It is possible
to reduce the amount of machinery?


Scopes and constraints are effectively conjunctions---shapes of constraints
and constraints of constraint components.  (There does not appear to be a
user-visible name for these components.)  Not all components can appear in
all kinds of constraints.  Component properties can only appear once in each
constraint even though most constraint components make sense when appearing
multiple times.  On the other hand the properties for constraints can appear
multiple times in a shape.

These restrictions make the language complex and irregular.  For example,
the following structure is illegal but natural:
  [ a sh:PropertyConstraint;
    sh:predicate ex:property1 ;
    sh:class ex:class1 ;
    sh:class ex:class2 ].
whereas the following would have the same meaning but is legal even though
less natural:
  [ a sh:PropertyConstraint ;
    sh:predicate ex:property1 ;
    sh:class ex:class1 ;
    sh:classIn ( ex:class2 ) ].
The following also has the same intuitive meaning
  [ a sh:PropertyConstraint ;
    sh:predicate ex:property1 ;
    sh:and ( [ a sh:Shape ;
            sh:constraint [ a sh:NodeConstraint ;
                    sh:class ex:class1 ] ]
      [ a sh:Shape ;
            sh:constraint [ a sh:NodeConstraint ;
                    sh:class ex:class2 ] ] ) ].
and might or might not be legal.

In some cases it is not possible to break out a conjunction within a single
constraint.  For example, the following is illegal but natural:
  ex:s1 a sh:Shape ;
    sh:property [ a sh:PropertyConstraint ;
        sh:predicate ex:property1;
    sh:equals ex:property2;
    sh:equals ex:property3 ].
To rewrite this in legal syntax requires two property cconstraints, as in
  ex:s2 a sh:Shape ;
    sh:property [ a sh:PropertyConstraint ;
        sh:predicate ex:property1;
    sh:equals ex:property3 ];
    sh:property [ a sh:PropertyConstraint ;
        sh:predicate ex:property1;
    sh:equals ex:property2 ].


It is possible to reduce the complexity and increase the regularity of the
SHACL language?


Constraint components can involve multiple properties in a constraint.  For
example, patterns components use sh:pattern and sh:flags, as in:
  [ a sh:Propertyonstraint ;
    sh:pattern "http:*" ;
    sh:predicate ex:httpURL ;
    sh:datatype xs:string ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:flags "i" ]
Determining the meaning of the pattern component requires looking for both
of its parts.  This adds to the complexity of reading SHACL constraints.  It
also adds to the complexity of processing SHACL constraints.

Is it possible to remove two-property aspects of the SHACL language?

Received on Tuesday, 8 March 2016 01:17:40 UTC