- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 7 Dec 2016 10:53:46 -0800
- To: public-data-shapes-wg@w3.org
I support Dimitris in this. The addition of the upper level class structure to the specification was enough to show that, although possibly expedient, the model is not logical. This makes it much harder for others to understand the meaning. kc On 12/7/16 1:06 AM, Dimitris Kontokostas wrote: > 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 <mailto: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 >> <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 >> <http://aksw.org/DimitrisKontokostas> >> Research Group: AKSW/KILT http://aksw.org/Groups/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 > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 7 December 2016 18:54:25 UTC