Re: Decomposing shapes

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.


> 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

Received on Friday, 14 October 2016 01:22:29 UTC