- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 14 Oct 2016 12:52:07 -0700
- To: public-data-shapes-wg@w3.org
On 10/13/16 6:21 PM, Holger Knublauch wrote: > > > On 13/10/2016 21:47, Dimitris Kontokostas wrote: >> There have been quite a few talks lately about what is a shape, focus >> nodes, referenced shapes, filters etc and most boil down to how shapes >> are used and different roles shapes take >> e.g. as a simple shape, as a filter shape, constraining shape (in >> sh:shape, sh:or, etc) >> >> One idea to fix this that came up after yesterday's telco with Karen >> was to differentiate these cases as follows >> A shape is a constraint with optional targets (currently shape is a >> subclass of Constraint so this is true anyway) >> All other cases will be referring to constraints, not shapes >> e.g. the range of a filter is a constraint, not a shape >> similar the range of sh:shape is again a constraint as for sh:and, >> sh:or, sh:qualifiedShape >> >> this fixes the problems of what we do with targets of a shape when >> that shape is referenced from another shape. With this change, the >> reference will be only to constraints, not shapes. > > I don't understand this. sh:Shape is a subclass of sh:Constraint. So > what would prevent anyone from using a sh:Shape as value of sh:filter? I > am also nervous that these suggested changes would make the language > less predictable as too many options would be allowed in too many > places. I actually like the current design to go through shapes for > these tasks. Holger, that was exactly the question: is it intended that a filter shape can have within its graph a "shape" (which can have targets and filters)? And if so, how is a filter shape different from "shape"? If there is no difference, then logically there is no filter shape, just a cascade of shapes that, when applied, define a focus node. In terms of predictability, having a filter shape able to include shapes, targets, and filters is less predictable than having a filter constraint that cannot also have shapes, targets and filters. One avoid the potential for a kind of infinite churning of shapes within shapes within shapes. kc > > Thanks, > Holger > > >> >> This will require the renaming of some SHACL Core constructs but I >> believe it will improve the language. >> e.g. sh:filterShape could be renamed to sh:filterConstrain, sh:filter, >> sh:condition >> sh:shape to sh:constraint >> sh:qualifiedValueShape to qualifiedValueConstraint >> (sh:not/or/and are not affected) >> >> Any feedback is welcome >> >> 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 >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 14 October 2016 19:52:38 UTC