Re: proposal for issue-211

here's the motivation behind this proposal
It makes shacl more flexible and simplifies the language and the metamodel
a lot with minimal changes in the current syntax and no effect on shacl full
it removes any corner cases  / grey areas that have been pointed out in the
past and we are patching / extending definitions to cover
It makes it much easier to explain and define SHACL.

Even though this requires to rewrite some parts of the spec, I believe it
will take us faster to CR

(attaching this to another issue is fine by me)


On Wed, Dec 7, 2016 at 10:25 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> Could you summarize what motivates this change? The "issue" mentioned in
> the email that you quote below is irrelevant. Users will *not* write such
> shapes. What is broken with the current design?
>
> Holger
>
>
>
> On 7/12/2016 17:38, Dimitris Kontokostas wrote:
>
> After a lot of thought, I would like to propose a change in shacl to close
> this issue.
>
> the change is a slight variation of Peter's proposal option #2 from this
> email
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html
>
> The variation adds the notion of sh:PropertyShape as a subClass of
> sh:Shape.
> This makes it easier to define some annotation properties like sh:label
> that make sense on properties only and gives us the option to keep
> sh:property in the language if we want to.
>
> if we decide to keep sh:property, it will become a constraint like
> sh:shape but it will make all our existing syntax valid and with the exact
> same behaviour.
> So this approach will have no effect on the existing syntax but will also
> regularise the language and enable some new shorter forms of shapes e.g.
>
> ex:S1 a sh:Shape ;
>   sh:targetClass ex:Person;
>   sh:property [
>     sh:predicate ex:name ;
>     sh:minCount 1 .
>   ]
>
> could be also written as
>
> ex:S1 a sh:Shape ;
>   sh:targetClass ex:Person;
>   sh:predicate ex:name ;
>   sh:minCount 1 .
>
> if we decide to drop sh:property we would use sh:shape instead and reduce
> the alternate ways we can define the same thing.
>
> I also checked this offline with Peter and he is willing to help us get
> the new terminology right should we decide to go this way
>
> Best,
> Dimitris
>
> --
> 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
>
>
>


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