Re: Decomposing shapes

On 14/10/2016 16:30, Dimitris Kontokostas wrote:
> 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 :)

I agree. I believe we should try and work on the explanation part before 
jumping to the conclusions that the SHACL language itself needs to be 
changed. Maybe we need to more explicitly spell out that the target 
mechanism is only used for the operation that validates all shapes in a 
given shapes graph, and to determine the shapes that apply to a given 
node. The current flow introduces the necessary concepts in the 
beginning of section 3 only, and this is apparently too late because 
terms like focus node are already used earlier. It is just really hard 
to put this into a right sequence of words, and I welcome input from 
other WG members. This could well be a topic for the F2F brainstorming.

Holger


>
> 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 <mailto: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
>>     <http://aksw.org/DimitrisKontokostas>
>>     Research Group: AKSW/KILT http://aksw.org/Groups/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
>