Re: Decomposing shapes

My reading of the current definition seems to be OK, but then I may have 
a different technical viewpoint than many other readers:

Afilteris ashape <#dfn-shape>in theshapes graph <#dfn-shapes-graph>that 
further refines thefocus nodes <#dfn-focus-node>in the data graph that 
are validated against aconstraint <#dfn-constraint>or all the 
constraints of ashape <#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 thosenodes <#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.

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