Re: Decomposing shapes

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.


> 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:,,
>> Homepage:
>> Research Group: AKSW/KILT

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 14 October 2016 19:52:38 UTC