W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: SHACL syntax and metamodel complexity

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 5 Mar 2016 16:33:41 -0800
To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <56DB7AE5.1070108@kcoyle.net>
Is there anything else (upon a quick reading, of course) that differs 
between the two models (and by that I mean 1-current SHACL and 2-Peter's 
proposal) in terms of functionality? If so, I think we're in line for a 
comparative table between the two, so that we can more easily see the 
differences.

kc

On 3/4/16 4:49 PM, Holger Knublauch wrote:
> In Proposal 3, SHACL itself can be used to check for well-formed SHACL
> models, because the ConstraintType and Parameter declarations can be
> used as shapes. No need for hard-coding that magic into UIs or "lint"
> tools.
>
> For example, this allows anyone to state that the values of sh:minCount
> must be xsd:integer. But also, constraints such as "there SHOULD only be
> one sh:minCount on the same property at the same shape" can be produced
> as a sh:Warning. Many of these are easy to formalize, and I anticipate
> that the SHACL community will contribute all kinds of such metashapes in
> the future.
>
> Holger
>
>
> On 5/03/2016 1:48, Peter F. Patel-Schneider wrote:
>> Some people believe that outlawing "useless" constructs or constructs
>> that
>> might be a mistake is a good idea.  I disagree.  However, SHACL does a
>> bad
>> job at outlawing "useless" constructs.
>>
>> 1/ ex:s1 a sh:Shape ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>                  sh:class ex:c1 ;
>>              sh:class ex:c2 ] .
>>
>> 2/ ex:s1 a sh:Shape ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>                  sh:class ex:c1 ] ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>              sh:class ex:c2 ] .
>>
>> 3/ ex:s1 a sh:Shape ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>                  sh:minCount 1 ;
>>              sh:minCount 2 ] .
>>
>> 4/ ex:s1 a sh:Shape ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>                  sh:minCount 1 ] ;
>>       sh:property [ a sh:PropertyContraint ;
>>                  sh:predicate ex:p1 ;
>>              sh:minCount 2 ] .
>>
>> Illegal: 1 and 3
>> "Useless":  3 and 4
>>
>> If "uselessness" is going to be a criterion for outlawing SHACL
>> constructs
>> then it should be uniformly applied.
>>
>> It is better to keep such constructs legal and leave it up to GUI and
>> lint-like tools to provide user guidance on potential mistakes.
>>
>> peter
>>
>> On 03/03/2016 05:57 PM, Irene Polikoff wrote:
>>> The only reason one would have multiple min and max counts is by
>>> mistake. To me, allowing this would be akin to encouraging errors and
>>> misunderstandings - thus, not a good idea. Prohibiting it, on the
>>> other hand, seems like a helpful thing and a good idea.
>>>
>>> Irene
>>>
>>> Sent from my iPhone
>>>
>>>> On Mar 3, 2016, at 5:45 PM, Peter F. Patel-Schneider
>>>> <pfpschneider@gmail.com> wrote:
>>>>
>>>>> On 03/03/2016 01:42 PM, Arnaud Le Hors wrote:
>>>>> "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on
>>>>> 03/03/2016
>>>>> 12:14:55 PM:
>>>>>
>>>>>> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>>>>>> To: kcoyle@kcoyle.net, public-data-shapes-wg@w3.org
>>>>>> Date: 03/03/2016 12:16 PM
>>>>>> Subject: Re: SHACL syntax and metamodel complexity
>>>>>>
>>>>>>> On 03/01/2016 09:20 PM, Karen Coyle wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 3/1/16 10:11 AM, Peter F. Patel-Schneider wrote:
>>>>>>>> in a simple extension of the current SHACL RDF syntax this would be
>>>>>>>>
>>>>>>>>       [ a sh:propertyConstraint ;
>>>>>>>>         sh:predicate ex:p ;
>>>>>>>>         sh:minCount 1 ;
>>>>>>>>         sh:class ex:c ;
>>>>>>>>         sh:maxCount 5 ;
>>>>>>>>         sh:class ex:d ;
>>>>>>>>         sh:minCount 3 ]
>>>>>>> Doesn't this require that there be order among the triples?
>>>>>> Otherwise, how do
>>>>>>> the two minCount's apply to the correct sh:Class triple?
>>>>>>>
>>>>>>> kc
>>>>>> No.  This is not a qualified cardinality.  What this says is that
>>>>>> there is at least one value for ex:p, that all values for ex:p
>>>>>> belong to ex:c,
>>>>>> that there are at most 5 values for ex:p, that all values for ex:p
>>>>>> belong to
>>>>>> ex:d, and that there are at least three values for ex:p.
>>>>> Ok, but the two minCounts are confusing. The first one (sh:minCount
>>>>> 1) is
>>>>> essentially overridden by the second (sh:minCount 3), right? So,
>>>>> why did you
>>>>> choose to have them both? What's the significance?
>>>>> --
>>>>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web
>>>>> Technologies - IBM
>>>>> Software Group
>>>> Right now, the SHACL syntax does not allow multiple minCounts, or
>>>> multiple
>>>> sh:class, or multiple anything.  Multiple minCounts are not useful.
>>>> Multiple
>>>> sh:class values are, however, and I view this as something that is
>>>> going to be
>>>> a pain point.
>>>>
>>>> Why are multiple sh:class values not allowed?  Well, multiples are
>>>> hard to
>>>> deal with if they are like the current design of qualified
>>>> cardinality, where
>>>> there are two property values that need to be combined.  So to
>>>> permit the
>>>> useful multiples one has to find a way to get around the combinations.
>>>>
>>>> The combinations are also problematic from a syntax viewpoint, as it
>>>> may be
>>>> hard to see the combination.  Thus my proposal is to refactor these
>>>> syntactic
>>>> constructs.  The result allows for repetition where useful and
>>>> permits it even
>>>> when it is not (very) useful.  Will users ever have multiple
>>>> minCounts (on
>>>> purpose)?  Probably not, but forbidding them doesn't seem like a
>>>> good idea.
>>>>
>>>> peter
>>>>
>>>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Sunday, 6 March 2016 00:34:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC