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

<I don't know where you get "typically." >



I donąt know if one can say only

ex:IssueShape
	a sh:Shape ;
	sh:scopeClass ex:Issue;
	sh:property [
		sh:predicate ex:state ;
	] ;


That is - mention the property, but have no constraints on the values. If
it is OK to define such a shape, to me this would be atypical thing to do
because it doesnąt serve much purpose. There could never be any
violations. With a closed shape, different story.

<I have a defined data schema
with more than 500 fields and 1400 separate data elements, and they are
either mandatory or optional. Since all but a few take uncontrolled
text, there's not much to constrain.>

What data violation checking would you expect on the optional fields?

<Majority of SKOS properties are min 0, max unlimited.

Can you cite your source for this? It actually doesn't make sense to me.>

Yes, http://www.w3.org/TR/skos-reference/



Irene 






On 9/25/15, 11:13 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>
>
>On 9/25/15 4:17 PM, Irene Polikoff wrote:
>> 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.
>
>I don't know where you get "typically." I have a defined data schema
>with more than 500 fields and 1400 separate data elements, and they are
>either mandatory or optional. Since all but a few take uncontrolled
>text, there's not much to constrain.
>
>I think we should quit talking about "typically." The world of metadata
>is very big and very diverse.
>
>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.
>
>My example was specifically with the defaults for cardinality within the
>open shape (which I think is a graph, but I don't care what we call it)
>method. That's what Harold's issue is about. Cardinality defaults in
>SHACL.
>
>>
>> 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.
>
>Can you cite your source for this? It actually doesn't make sense to me.
>
>kc
>
>>
>> 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
>>>
>>
>
>-- 
>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 17:03:30 UTC