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

14 is about motivation, not relevant
15 is about list parameters, not relevant
16 is about shifting effort, not possibility
17 is about uniform syntax, not possibility
18 is about access to the shapes graph, not relevant
19 is about accessing parameters, not relevant
20 is about multiple optional blocks, not possibility
21 is about separating the property part from the other part
22 is about mixing properties and shapes, not relevant
23 is about only having a single parameter to a function, not relevant

As far as 21 goes:
The current implementation requires each constraint component (like
sh:minCount) to access the sh:property, so that it can get the property
values for itself.  So, yes, in this setup every constraint component needs
at least two properties, one being sh:predicate.  However, this is only a
feature of the current implementation (and really only of the current syntax
as well) not of the language itself.

peter


On 03/10/2016 03:18 AM, Holger Knublauch wrote:
> 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 23:03:09 UTC