Re: Decomposing shapes

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