- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 29 Oct 2015 15:58:26 -0400
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Karen, Done. sh:allowedValues is renamed to sh:in. Let me know if the text still needs work. -- Arthur On Thu, Oct 29, 2015 at 3:44 PM, Arthur Ryman <arthur.ryman@gmail.com> wrote: > Karen, > > I'll edit the text to make it clearer. > > -- Arthur > > On Sat, Oct 17, 2015 at 9:23 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: >> Thanks, Holger. The difference wasn't clear to me in the spec. For now, the >> definitions are: >> >> sh:hasValue: The property sh:hasValue can be used to verify that the focus >> node has a given RDF node among the values of the given predicate. >> >> sh:allowedValues: The property sh:allowedValues can be used to enumerate the >> values a property can have. When specified, the value of the given property >> must be members of the specified set. >> >> With some hindsight I see the meanings, but I must say it possibly could be >> clearer. Also "value... must be members... set" has some mixing of singular >> and plural that makes it harder to understand. Is there some reason why we >> can't say what you say below? (Maybe Arthur could add this to his edits?) >> >> kc >> >> >> On 10/17/15 5:10 PM, Holger Knublauch wrote: >>> >>> The difference is that sh:hasValue is *existential*, i.e. the property >>> must have the given value but it may also have others that are no >>> enumerated. On the other hand, sh:in is *exclusive*, i.e. no other >>> values than the enumerated ones are permitted. >>> >>> Holger >>> >>> >>> On 10/18/15 5:31 AM, Karen Coyle wrote: >>>> >>>> Will this also be used for lists of one value? I ask because I was >>>> noticing that the current draft has sh:hasValue as well as >>>> sh:allowedValues, even though logically a list of one is ... one. It >>>> would make sense to me that if there is only one possible value (which >>>> doesn't sound to me like a common case, but perhaps it is in other >>>> environments) users would not have to use a different property. That's >>>> a decision/switch that a program can make for the user. >>>> >>>> kc >>>> >>>> On 10/16/15 7:48 PM, Holger Knublauch wrote: >>>>> >>>>> It basically means that the node must be *member of* the given list. >>>>> When used via sh:constraint (as below) it means that all nodes where the >>>>> shape applies to must be members of this set - if the shape is validated >>>>> against ex:Blue then a violation is fired. When used via sh:property >>>>> this means that all values must be members of the list. >>>>> >>>>> Holger >>>>> >>>>> >>>>> On 10/17/15 10:42 AM, Karen Coyle wrote: >>>>>> >>>>>> Sorry, I've forgotten what we said "in" means - one of? any of? >>>>>> >>>>>> kc >>>>>> >>>>>> On 10/15/15 1:55 PM, Holger Knublauch wrote: >>>>>>> >>>>>>> Following today's resolution on ISSUE-98, I propose to close ISSUE-84 >>>>>>> using sh:in, e.g. >>>>>>> >>>>>>> ex:TrafficLightColors >>>>>>> a sh:Shape ; >>>>>>> sh:constraint [ >>>>>>> sh:in (ex:Green ex:Red ex:Yellow) >>>>>>> ] . >>>>>>> >>>>>>> I also suspect we may now close ISSUE-88 using the node constraints >>>>>>> from >>>>>>> ISSUE-98, but this would need to be confirmed by Jose. >>>>>>> >>>>>>> Holger >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet/+1-510-984-3600 >>
Received on Thursday, 29 October 2015 19:58:54 UTC