- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 16 Oct 2016 14:18:26 -0700
- To: public-data-shapes-wg@w3.org
On 10/15/16 9:11 PM, Holger Knublauch wrote: > My reading of the current definition seems to be OK, but then I may have > a different technical viewpoint than many other readers: > > A filter is a shape <#dfn-shape> in the shapes graph > <#dfn-shapes-graph> that further refines the focus nodes > <#dfn-focus-node> in the data graph that are validated against > a constraint <#dfn-constraint> or all the constraints of a shape > <#dfn-shape>. A filter is specified as an object in a triple > with|sh:filterShape| as the predicate. The subjects of these triples can > be constraints or shapes. Only those nodes <#dfn-node>that successfully > validate against all the filters of a constraint or a shape become focus > nodes for the constraint or the constraints of the shape. > > This doesn't say that being a filter shape excludes any other uses of a > shape. It's just one role among others. > > In general I do have concerns about the concept of filter shapes. They > are a nice-to-have syntactic short cut, esp to manipulate existing shape > definitions, but otherwise their effect can be achieved via sh:and > already. The thing that I dislike about filter shapes is that they > introduce a non-monotonic construct where subclasses can have fewer > constraints than superclasses. This makes the whole language quite > unpredictable. I believe it also makes the language non-conformant with RDF. One solution would be to have an sh:Filter class which is a subclass of sh:constraint but not of sh:Shape. It's the subclassing to sh:Shape that seems to cause the problems if it isn't intended to have all of the qualities of that class. I would be interested to hear from others who have implemented sh:filterShape and what it means in their applications. It seems to me that filters act quite differently from sh:and. kc > > So if people continue to struggle with this feature, I'd be ready to > drop it from the language. sh:filterShape is easy to take out on a short > notice. Having said this, we already use sh:filterShape in practice in > our products. > > Holger > > > > On 15/10/2016 6:45, Irene Polikoff wrote: >> My understanding is that “filter shape” is a role that any shape can >> play for another shape or for a constraint. Exactly the same shape can >> also exist on its own, separate from any references. There is nothing >> intrinsic about being a filter shape. >> >> If so, this language needs adjusting: >> >> A filter is a shape in a shapes graph that can be used to limit >> the nodes that are validated against a given constraint. Only >> those nodes that validate against all the filters are validated. A >> filter is specified with the sh:filterShape predicate. >> >> >> Maybe >> >> A shape in a shapes graph can be used to limit the nodes that are >> validated against another shape or a specific constraint. The fact >> that a shape is playing a filter role is specified using the >> sh:filterShape predicate. >> >> >> May be the fact that any shape could play this role would be clearer >> if the language required to have that shape defined separate and not >> as an inline anonymous node. With this, users would always have to say >> sh:filterShape e:MyShape. >> >> <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.> >> >> Well, a constraint can also have filters, so we get infinite churning >> either way. >> >> >> Irene >> >> >> >> On 10/14/16, 3:52 PM, "Karen Coyle" <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> >> >> 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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet/+1-510-984-3600 >> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Sunday, 16 October 2016 21:18:57 UTC