Re: Decomposing shapes

Another option to minimise the changes in the model is to introduce
something like
sh:ShapeWithTarget that is a subclass of sh:Shape and leave the rest as is

or, of course, continue with the current design but try to explain better
the role of targets in different shape contexts

I am only raising an issue that was brought up and needs some attention.
I also think it is confusing to understand this because I am having trouble
explaining it in a concise & simple way :)

personally, I am not a big supporter of any option.
If we had more time as WG I would probably favour the mass renaming
(including Erics suggestions) but I am afraid of how much this will delay us

Thanks,
Dimitris

On Fri, Oct 14, 2016 at 4:21 AM, Holger Knublauch <holger@topquadrant.com>
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.
>
> 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
>
>
>


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