Re: SHACL syntax and metamodel complexity

On 4/03/2016 10:10, Peter F. Patel-Schneider wrote:
> On 03/03/2016 03:50 PM, Holger Knublauch wrote:
>> On 4/03/2016 9:29, Peter F. Patel-Schneider wrote:
>>> This wording is extremely confused.   It is possible to have multiple
>>> constraint components on the same property in one component, such as a
>>> minCount and a class.  The confusion comes from using "property" for two
>>> different things.
>> I have replaced the second use of "property" with "predicate" to make this
>> clearer.
>>
>> In your approach, if you have multiple sh:class values, are they being
>> interpreted as AND or OR?
> These would be conjuctive, of course, just as a sh:class and an sh:minCount
> would be conjunctive.

Well, then just use multiple sh:property constraints, e.g.

ex:MyShape
     a sh:Shape ;
     sh:property [
         sh:predicate ex:myProperty ;
         sh:class ex:Type1 ;
     ] ;
     sh:property [
         sh:predicate ex:myProperty ;
         sh:class ex:Type2 ;
     ] ;

There is no need to overhaul everything just for the rare cases where 
you need such intersections.

>
>
>> Note that in either case this multi-occurrence within the same property
>> constraint causes a serious limitation by disallowing constraint types that
>> have multiple parameters such as sh:pattern/sh:flags. I guess that's one
>> reason why you (silently) dropped the extension mechanism, because this would
>> quickly expose this limitation as another show stopper.
>>
>> Holger
> Not at all.
>
> First, constraint types that have multiple parameters are a horrible syntax.
> It is too easy to have the two parameters separated.  It is too easy to
> consider the parameter values in isolation.
>
> Instead, constructs that need more than a single item of information (like
> sh:pattern) can take structured piece of information.  This can either be a
> list or a node that itself has multiple properties.  So, patterns with flags
> can be specified as
>    sh:pattern ("a*b*" "i")

-1 from me on this. This will not lead to a user-friendly syntax. If 
people want to group their parameters for clarification, they can 
already do so by creating multiple property constraints.

>
> The same approaches work for templates.

Your "metamodel" doesn't talk about extensions at all. If you want this 
to be seriously considered, please work out the details, including 
Turtle files etc. I spent a lot of time on coming up with a detailed 
design based on the feedback that I got from the group. I believe 
Proposal 3 addresses all concerns. Now, in March 2016 you come up with 
radical changes all over again. This is very unhelpful. You should have 
brought up these issues sometime last year. At some stage we need to 
stabilize things, and expose them to tests.

Holger

Received on Friday, 4 March 2016 00:21:09 UTC