Re: Please vote on ISSUE-211

As I understand it, constraint, as represented by sh:Constraint, is a condition data must meet. Both sh:Shape and sh:PropertyConstraint can represent such conditions.

They have this in common and this is why they are both subclasses of sh:Constraint. However, the conditions they can represent are different. For example, sh:PropertyConstraint represents only conditions that are specific to the property values of a focus node. Shapes, on the other hand, in the current design represent conditions that are about the focus node itself. For example, shapes can be marked "closed", which is a constraint that "goes across" many properties. When you say that it is closed, you are not talking about a value of any specific property.

(Btw, there is also sh:SPARQLConstraint, which is another subclass of sh:Constraint not shown in the diagram. And shjs:JavaScriptConstraint as an extension point for the future.)

It is a very common pattern to have subclasses to group together their relevant properties, and have a shared superclass. This is similar to having a model that has a class Party and subclasses Person and Organization where Party is used to represent the commonality between a person and organization.  People and organizations are all parties. Classes Person and Organization are used to model the variability between them. Of course, if one never needs to explicitly talk about and describe Organizations, one could just have a model that only has a class Party and a class Person. They would associate with the class Person all qualities that are unique to people and associate with the class Party all other qualities including those that are common only to Organizations. But doing so makes it impossible to explicitly talk about parties that are not people or base software logic on the unique qualities of the parties that are not people.


With the change proposed by Dimitris, one would not, for example, be able to explicitly talk about only the specific set of shapes that could be marked as closed. There would be nothing to represent them. “Property shapes” can’t be closed. “Shapes” would represent a set of things that combine shapes that can be closed with those that can not be closed since it is a parent class of property shapes. As Dimitris says, there would be only shapes that work on value nodes and shapes that work on all nodes. This means that we can no longer talk about shapes that can not work on the value nodes.

Irene

> On Dec 12, 2016, at 4:53 PM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> 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 <mailto: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>
> <mailto: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=Proposals#ISSUE-211:_Eliminate_property_constraints <https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-211:_Eliminate_property_constraints>
>         <https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-211:_Eliminate_property_constraints <https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#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> <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> http://kcoyle.net <http://kcoyle.net/>
>     m: 1-510-435-8234
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> <tel:%2B1-510-984-3600>
> 
> 
> 
> 
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>,
> http://aligned-project.eu <http://aligned-project.eu/>
> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
> 
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://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://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
> 
> <shape-control.text>