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

Peter, such a response is not a helpful dialogue. This is fighting over 
words instead of substance.

Yes, formally you are right: it is POSSIBLE to remove the two-property 
aspects of SHACL (except for functions which you are glancing over).

So let me rephrase my response:

Yes, but it makes no sense to do that for the reasons listed. Problems 
are simply shifted around, not solved.

You started motivating your proposal to address complexity and 
usability. Unfortunately the choice to disallow multiple parameters 
creates more issues than it solves. Would you like to respond on this 
ground?

Holger


On 11/03/2016 9:02, Peter F. Patel-Schneider wrote:
> 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:20:06 UTC