Re: shapes-ISSUE-39 (Value shape facet): Naming of value shape facet [SHACL Spec]

The current votes are

HK: sh:shape > sh:valueShape
SSt: sh:shape > sh:valueShape
RC: sh:shape > sh:valueShape
DK: sh:valueShape

PROPOSAL: Based on the votes at 
https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names#Value_Shape the 
name of the core vocabulary property previously known as sh:valueShape 
should be sh:shape.

I acknowledge that this didn't really get enough votes overall, so I'd 
be happy to update the proposal if more votes are coming in.

Likewise the two other open votes at

     https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names

are too close to call at this stage - I would appreciate more opinions.

Holger


On 4/6/15 6:37 AM, Irene Polikoff wrote:
> The reason I asked was because you said
>
> <"valueShape" reads to me as "appleOrange", and that section of the
> document isn't clear for this reason. Also, that section only shows a
> nested example. The text should make clear that the value can be a
> literal, a datatype, or a node, and should show how one indicates those. I
> am particularly interested in how one would create a constraint that
> limits the value to a particular literal list, and another example that
> shows limiting to a particular RDF-defined vocabulary.>
>
>
> I do not believe that sh:valueShape (predicate 3 in my email) is intended
> to support saying that the value must be a literal or a node (by node, I
> assume, you mean IRI or a blank node). Instead, this can be done using
> predicate 2 (sh:nodeKind/sh:nodeType/or whatever is decided as its name).
>
> Datatype is indicated using sh:datatype - yet another predicate. Nor is
> sh:valueShape intended to limit the values to a list. I believe the
> predicate intended for that is sh:allowedValues.
>
> Limiting to a particular RDF vocabulary can be done using predicate 1
> (sh:valueType/sh:class/or whatever decided as its name), assuming that
> this is about indicating membership in a class that is defined in a
> vocabulary. For example, a vocabulary could have a class example:Country
> and resources example:USA rdf:type example:Country, etc.
>
> If you are also thinking of a vocabulary that doesnıt declare its own
> classes and uses classes from another vocabularies, this could mean that a
> resource from vocabulary A is a member of class that is defined in a
> vocabulary B. The class is broadly used (e.g., skos:Concept) and some
> other vocabularies C, D, etc. may also have resources of the same type. In
> this case, I am not quite sure how one could determine that a resource is
> a member of a vocabulary A. Possibly, this could be about saying that IRIs
> must start with something e.g., "www.example.com/³ must be at a start of
> the IRI.
>
> Irene
>
> On 4/4/15, 12:58 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>
>> No, that is unrelated to my comment.
>>
>> kc
>>
>> On 4/4/15 9:37 AM, Irene Polikoff wrote:
>>> Karen,
>>>
>>> As I understand it, different predicates are proposed for describing
>>> what a value of a property should be. The best names for these
>>> predicates are still being discussed, so I am just calling these
>>> predicate 1, 2 and 3:
>>>
>>> Predicate 1 allows one to say that values of a property must be members
>>> of a certain class.
>>>
>>> For example, values of :nationality must be members of class :Country.
>>> This allows limiting the values to some RDF vocabulary.
>>>
>>> Predicate 2 allows one to say that values of a property must be a
>>> literal or it must be an IRI or it must be a blank node.
>>>
>>> Predicate 3 allows one to say that values of a property must comply
>>> with a specified shape. This is what 'valueShape' is about.
>>>
>>> Could it be that you are wondering why three separate predicates are
>>> needed?
>>>
>>> Irene
>>>
>>>
>>>> On Apr 4, 2015, at 10:30 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>>
>>>> I wasn't able to answer this one because the property, as defined,
>>>> doesn't make sense to me.
>>>>
>>>> The definition in the document is: "The property sh:valueShape can be
>>>> used verify that all values of the given property must match a given
>>>> shape."
>>>>
>>>> But in the introduction, there is a clear separation between node
>>>> constraints and property contraints:
>>>>
>>>> "A shape describes a group of local constraints with the same focus
>>>> node. Many of these constraints are about a certain property only, and
>>>> these are called property constraints."
>>>>
>>>> To me, constraints on values are property constraints, while
>>>> constraints on the content or shape of the node (e.g. the properties
>>>> and classes) are shape constraints. Thus the statement "all values of a
>>>> given property must match a given shape" would make more sense as "all
>>>> values of a given property must match the property constraint".
>>>>
>>>> "valueShape" reads to me as "appleOrange", and that section of the
>>>> document isn't clear for this reason. Also, that section only shows a
>>>> nested example. The text should make clear that the value can be a
>>>> literal, a datatype, or a node, and should show how one indicates
>>>> those. I am particularly interested in how one would create a
>>>> constraint that limits the value to a particular literal list, and
>>>> another example that shows limiting to a particular RDF-defined
>>>> vocabulary.
>>>>
>>>> kc
>>>>
>>>>> On 4/2/15 4:21 PM, RDF Data Shapes Working Group Issue Tracker wrote:
>>>>> shapes-ISSUE-39 (Value shape facet): Naming of value shape facet
>>>>> [SHACL Spec]
>>>>>
>>>>> http://www.w3.org/2014/data-shapes/track/issues/39
>>>>>
>>>>> Raised by: Holger Knublauch
>>>>> On product: SHACL Spec
>>>>>
>>>>> See https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names
>>>>>
>>>>> How should the facet property for value shapes be called? Please cast
>>>>> your vote on the page linked above.
>>>> --
>>>> 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 Wednesday, 8 April 2015 20:24:55 UTC