Re: Please vote on ISSUE-211

On 13/12/2016 2:47, Dimitris Kontokostas wrote:
> Hi Karen,
>
> if we keep sh:property in the language the syntax will be 100% 
> identical with the current syntax,

No, e.g. you suggest to rename sh:PropertyConstraint to 
sh:PropertyShape. And removing sh:property would basically invalidate 
every known example of SHACL.

> 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

There will be changes, and new issues will have to be discussed. It 
would be possible to either state

ex:PersonShape
     a sh:Shape ;
     sh:property [
         sh:predicate ex:address ;
         sh:maxCount 1 ;
     ] .

or

ex:PersonShape
     a sh:Shape ;
     sh:shape [
         sh:predicate ex:address ;
         sh:maxCount 1 ;
     ] .

New questions that would need to be reopened include "what is the 
expected type of sh:shape", "how to identify property shapes - by the 
presence of sh:predicate/sh:path or via rdf:type triples", "what happens 
if a node with rdf:type sh:Shape declares a sh:predicate", "how does 
sh:SPARQLConstraint fit into the picture". These are exactly the same 
kind of questions that we have wrestled (with Peter in particular) over 
the last year. The new proposal is merely resetting the discussion, 
while the current design has been read by many people several times over 
and we have eliminated issue after issue.

>
> this change in the metamodel will result in a simplication of the 
> definitions in section 2.

That's largely a matter of taste.

> 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

None of the arguments are IMHO strong enough to cause a redesign of the 
metamodel given the current time line. We have plenty of other open tickets.

Holger


>
>
>
>
> 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=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> 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
>