Re: Please vote on ISSUE-211

Hi Karen

I attach a re-write of the spec that was provided by Peter for his original
proposal. My variation for PropertyShape (or ValueShape see below) is a
small addition in this

see inline for more details

On Mon, Dec 12, 2016 at 8:13 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> OK, but I don't feel that I can vote until I fully understand the
> implications.
>
> 1) What these seems to do is to remove the superclass sh:Constraint from
> the model - is that the case? Does it do anything else?
> --I would favor this because of the confusion caused by sh:Constraint vs.
> a set of properties that are referred to as "constraints" in the spec. I
> would also favor it because having both shapes and property constraints as
> subclasses of sh:Constraint does not make sense to me as a mental model of
> a validation vocabulary. (The current model seems to describe service
> functionality rather than vocabulary logic.)
>

Yes, sh:Constraint is removed and we have only shapes


> 2) This still seems to treat "node shapes" and property shapes
> differently. Node shapes are subsumed into shape. If this is the case, then
> I would prefer that shape be defined clearly as including node shapes - the
> way the two-class diagram reads today, node shapes are not at all visible.
> From the point of view of someone wanting to understand SHACL, this is not
> good.
>

Yes, this remains the same as the current spec (shape = focus node
constraint).  One way to make this more clear is to say that we have shapes
that operate on nodes and shapes that operate on value nodes, the former
are called Shapes and the latter ValueShapes. This would amend my proposal
and rename PropertyShapes to ValueShapes if it makes sense to others, which
is only a name change


> 3) There needs to be a fairly complete user view of the SHACL language. I
> tried developing one informally, but got stuck. I will try again. In any
> case, the user view must be included in the specification OR there could be
> two specifications - language and processing rules. Or, as they are divided
> in the SPARQL world, query language and service description. At the moment,
> the two are intermixed in the spec, and neither is entirely clear.
>

I think this is a different topic

>
> kc
>
> On 12/12/16 8:47 AM, Dimitris Kontokostas wrote:
>
>> Hi Karen,
>>
>> if we keep sh:property in the language the syntax will be 100% identical
>> with the current syntax,
>> if we decide to drop sh:property, we will use sh:shape instead.
>> So, there will be very little to no change in the current syntax /
>> structure of shapes
>>
>> this change in the metamodel will result in a simplication of the
>> definitions in section 2.
>> This will enable some SHACL constructs like targets to be used in what
>> we have now as PropertyConstraints,
>> so, this change additionally enables some new shape structures / syntax
>> that are now forbidden with prose in the spec.
>>
>> I also agree with Irene that ~90% of the users will not use the new
>> enabled shortcuts.
>> For the rest 10%, personally I find it more intuitive with this proposal
>> and I feel like  the simplification in the spec further justifies it
>>
>>
>>
>>
>> On Mon, Dec 12, 2016 at 5:57 PM, Karen Coyle <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>     I would like to see an example of how this works when there are
>>     multiple property constraints. I believe that was the problem that
>>     Irene saw with it, and sh:property has been explained to me as a way
>>     to gather constraints into a graph.
>>
>>     kc
>>
>>
>>     On 12/12/16 6:48 AM, Arnaud Le Hors wrote:
>>
>>         Hi all,
>>
>>         Dimitris made a proposal to close this issue based on one of
>> Peter's
>>         proposals. Holger opposes it. This is seen by both as an important
>>         decision for the WG to make so I would like people to vote in
>>         the wiki
>>         on which one they prefer and/or can live with.
>>         https://www.w3.org/2014/data-shapes/wiki/index.php?title=Pro
>> posals#ISSUE-211:_Eliminate_property_constraints
>>         <https://www.w3.org/2014/data-shapes/wiki/index.php?title=Pr
>> oposals#ISSUE-211:_Eliminate_property_constraints>
>>
>>         Of course once you're done with that one I encourage you to look
>>         at and
>>         vote on the other issues too. :-)
>>         Thanks.
>>         --
>>         Arnaud  Le Hors - Senior Technical Staff Member, Open Web &
>>         Blockchain
>>         Technologies - IBM Cloud
>>
>>
>>     --
>>     Karen Coyle
>>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234
>>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>>
>>
>>
>>
>> --
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>> http://aligned-project.eu
>> Homepage: http://aksw.org/DimitrisKontokostas
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT