- From: Irene Polikoff <irene@topquadrant.com>
- Date: Mon, 21 Sep 2015 06:38:05 +0200
- To: <kcoyle@kcoyle.net>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Thanks Karen. I am now more clear that this is a qualified cardinality constraint. In my experience, qualified cardinality constraints are somewhat rare and there are viable modeling alternatives for them - which is why OWL didn’t support them until release 2.0. Even after they became supported, the feature is not much used - again, in my experience. A common modeling alternative is to use different properties for different value types and, if desired, make them a sub property of a common property. I am not trying to say that the examples of this pattern are uncommon for your domain, only sharing my experiences. As I understand it, this also about particular qualified cardinality constraints where constraints on the values are of certain kind. I am thinking this because, in a more general sense, qualified cardinalities are supported in SHACL. So, examples with real data would indeed help a lot. One more question. What does “one instance of S” mean? Do you mean (this is how I interpreted it): There must be one triple with S as a subject, P as a predicate and an object of type V1 and two triples with S as a subject, P as a predicate and objects of type V2? Or do you mean There must be one triple with with a subject of type S, P as a predicate and an object of type V1 and two triples with a subject of type S, P as a predicate and objects of type V2? In the second example, subjects are different IRIs, but they all have the same rdf:type. Irene Polikoff On 9/21/15, 7:57 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >Irene, the way I intend it is this: > >For subject S, and property P... > >one instance of S, P must have value of type V1 >two instances of S, P must have value of type V2* > >It could just as easily be: > >one instance of S P must have value of type V1 >one instance of S P must have value of type V2 > >or any other combination of cardinalities. The exact cardinality is not >important. Nor is the exact set of values. The purpose of the example is >to show that properties will be re-used with different value types. This >will happen in general vocabularies like Dublin Core and Schema.org. >I'll do what I can to locate some live data that shows this. > >kc >* This is the "Chinese menu" pattern: one from column A, two from column >B. The "types" here could be different lists that one chooses from. > >On 9/20/15 5:06 PM, Irene Polikoff wrote: >> Karen, >> >> Is this requirement about the ability to say Œor¹ as in: >> >> Œthe value of this property cold be either an integer or a date¹ >> >> Or is it about the ability to do qualified cardinality constraints as >>in: >> >> Œat least one value must be an integer and at least one value must be a >> date¹ >> >> >> Irene Polikoff >> >> >> >> >> >> >> On 9/20/15, 10:19 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >> >>> >>> >>> On 9/20/15 1:39 AM, Holger Knublauch wrote: >>>> On 9/19/15 5:02 PM, Karen Coyle wrote: >>>>> 2) repeated properties >>>>> This is a real and not uncommon example: >>>>> >>>>> <bf_Person1> >>>>> bf:identifiedBy >>>>><http://id.loc.gov/authorities/names/n80103961#RWO> ; >>>>> #IRI from id.loc.gov, min 1, max 1 >>>>> bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> >>>>>. >>>>> #IRI from viaf.org, min 1, max unlimited >>>> >>>> I agree it makes sense to talk about the requirements before >>>>requesting >>>> a change to the language. If I understand the intention correctly, >>>>then >>>> the above could be expressed with an incremental addition to the core >>>> library: >>>> >>>> ex:MyShape >>>> a sh:Shape ; >>>> sh:property [ >>>> sh:predicate bf:identifiedBy ; >>>> sh:qualifiedMinCount 1 ; >>>> sh:qualifiedMaxCount 1 ; >>>> sh:qualifiedValueShape [ >>>> sh:constraint [ >>>> a sh:URIPatternConstraint ; >>>> sh:uriPattern "^http://id.loc.gov" ; >>>> ] ; >>>> ] ; >>>> ] ; >>>> sh:property [ >>>> sh:predicate bf:identifiedBy ; >>>> sh:qualifiedMinCount 1 ; >>>> sh:qualifiedValueShape [ >>>> sh:constraint [ >>>> a sh:URIPatternConstraint ; >>>> sh:uriPattern "^http://viaf.org" ; >>>> ] ; >>>> ] ; >>>> ] . >>>> >>>> The new feature that would be needed would be sh:URIPatternConstraint >>>>- >>>> the current sh:pattern only applies to property values "one hop away" >>>> while here we would need something that talks about the IRI of the >>>>focus >>>> node itself. We had a similar topic recently with regards to >>>> sh:allowedValues. It may make sense to generalize the validation >>>> function mechanism so that the same infrastructure can be reused, but >>>>in >>>> the end this is about syntactic sugar only. >>> >>> In fact, the question was less about the URI pattern than about the >>> ability to have different values for the same property, and to >>>constrain >>> them separately. So we should pick some other value constraints to use >>> that SHACL already handles -- perhaps that the first instance is an IRI >>> and the second is a literal. Looking at the above, I think both would >>> fail when the "other" value is evaluated. >>> >>> Wouldn't this be a case that could use sh:filterShape? That is, there >>> would be a separate sh:filterShape for the two different cases. By >>>using >>> the filter, only one value type would be included in the graph being >>> evaluated. >>> >>> If that works, then I have a follow-up question. >>> >>> Thanks, >>> kc >>> >>>> >>>> Holger >>>> >>>> >>>> >>> >>> -- >>> 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 Monday, 21 September 2015 10:38:38 UTC