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

You asked

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

My answer is "no", for the various reasons outlined as 14) - 23) in my 
recent email

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html

You asked

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

I believe SHACL (as outlined in proposal 3) is already sufficiently 
regular and not too complex.

Holger



On 8/03/2016 11:17, RDF Data Shapes Working Group Issue Tracker wrote:
> 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 Thursday, 10 March 2016 11:18:41 UTC