- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 5 Mar 2016 10:49:24 +1000
- To: public-data-shapes-wg@w3.org
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 >>> >>>
Received on Saturday, 5 March 2016 00:49:59 UTC