Re: Decomposing shapes

All the examples show an inline shape. The definition doesn't say one way or the other making it easy to assume that the filter shape must be specified inline and, thus, can't be anything else.

Sent from my iPhone

> On Oct 16, 2016, at 5:11 AM, Holger Knublauch <holger@topquadrant.com> 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 in the shapes graph that further refines the focus nodes in the data graph that are validated against a constraint or all the constraints of a shape. A filter is specified as an object in a triple withsh:filterShape as the predicate. The subjects of these triples can be constraints or shapes. Only those nodesthat 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> 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 http://kcoyle.net
>> m: 1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>