Re: shapes-ISSUE-91 (hsolbrig): Default Cardinality [SHACL Spec]

Karen, I think you meant open shapes and closed shapes, not open and closed graphs which is not something the group has defined.

Even without cardinality, there is typically some other constraint - that is a constraint on the value. Further, one could specify only minCardinality or only maxCardinality, leaving the other one to default. With this, not specifying constraints for both min and max cardinality ( or even for neither) would not be meaningless from the data validation perspective - there are still things to check with open shapes.

I think there are two criteria to consider regarding default:

1. Intuitiveness

To me, if there is no cardinality constraint stated, the intuitive interpretation is that there is no constraint.

2. Verbosity

This, of course, will very much depend on the model, but we can look the commonly used vocabularies such as SKOS. Expressing SKOS in SHACL for constraint checking would be much more verbose if the default min 1, max 1. Majority of SKOS properties are min 0, max unlimited.

We could look it other models as well.  I find that proportion of properties that are {min 1, max 1} is much smaller than properties that are either {min 0, max unlimited} or {min 1, max unlimited} or {min 0, max 1 (or some other number)}. All of these would require more verbosity if the default was min 1, max 1.

Sent from my iPhone

> On Sep 25, 2015, at 8:15 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> 
> I think that the cardinality defaults interact with the closed/open graph definition. If the graph is open, then a default of "minCardinality = 0, maxCardinality = *" is pretty close to meaningless. In an open graph, all potential predicates are "optional" unless defined otherwise, and specifying optional predicates does not invoke any useful behavior. In the case of an closed graph, "minCardinality = 0" describes a specific optional predicate.
> 
> SHACL, if I understand it correctly, describes an open graph by default. This means that only ""minCardinality > 0" can be validated.
> 
> Although the statement by Holger that "if something is left unspecified then it should count as unconstrained" resonates, I would consider the inclusion of a optional property to be specified, not unspecified.
> 
> kc
> 
>> On 9/25/15 1:02 AM, Holger Knublauch wrote:
>> I believe if something is left unspecified then it should count as
>> unconstrained. So if no sh:minCount or sh:maxCount is given then it
>> should count as 0..* by default.
>> 
>> PROPOSAL: Close ISSUE-91 stating that the default interpretations of
>> sh:minCount and sh:maxCount (and their qualified counterparts) should
>> remain as currently specified.
>> 
>> Holger
>> 
>> PS: A compact syntax may of course use different conventions and
>> automatically generate the corresponding min/max triples.
>> 
>> 
>>> On 9/25/2015 0:46, RDF Data Shapes Working Group Issue Tracker wrote:
>>> shapes-ISSUE-91 (hsolbrig): Default Cardinality [SHACL Spec]
>>> 
>>> http://www.w3.org/2014/data-shapes/track/issues/91
>>> 
>>> Raised by: Harold Solbrig
>>> On product: SHACL Spec
>>> 
>>> The defaults for cardinality in UML are [1..1]  (see:
>>> MultiplicityElement.lowerBound() and MultiplicityElement.upperBound()
>>> on page 41 of OMG specification ptc/2013-09-05).  Should these be the
>>> defaults for mincount and maxcount in Section 3.1.5 of the SHACL
>>> specification as well?  Currently they are [0..*].
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>

Received on Friday, 25 September 2015 14:23:54 UTC