- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 21 Sep 2015 07:57:32 +0200
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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 05:58:05 UTC