W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > October 2016

Re: Decomposing shapes

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sun, 16 Oct 2016 14:18:26 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <e011f71e-e594-7bc1-73db-250b0c0a42f4@kcoyle.net>


On 10/15/16 9:11 PM, Holger Knublauch wrote:
> My reading of the current definition seems to be OK, but then I may have
> a different technical viewpoint than many other readers:
>
> A filter is a shape <#dfn-shape> in the shapes graph
> <#dfn-shapes-graph> that further refines the focus nodes
> <#dfn-focus-node> in the data graph that are validated against
> a constraint <#dfn-constraint> or all the constraints of a shape
> <#dfn-shape>. A filter is specified as an object in a triple
> with|sh:filterShape| as the predicate. The subjects of these triples can
> be constraints or shapes. Only those nodes <#dfn-node>that successfully
> validate against all the filters of a constraint or a shape become focus
> nodes for the constraint or the constraints of the shape.
>
> This doesn't say that being a filter shape excludes any other uses of a
> shape. It's just one role among others.
>
> In general I do have concerns about the concept of filter shapes. They
> are a nice-to-have syntactic short cut, esp to manipulate existing shape
> definitions, but otherwise their effect can be achieved via sh:and
> already. The thing that I dislike about filter shapes is that they
> introduce a non-monotonic construct where subclasses can have fewer
> constraints than superclasses. This makes the whole language quite
> unpredictable.

I believe it also makes the language non-conformant with RDF. One 
solution would be to have an sh:Filter class which is a subclass of 
sh:constraint but not of sh:Shape. It's the subclassing to sh:Shape that 
seems to cause the problems if it isn't intended to have all of the 
qualities of that class.

I would be interested to hear from others who have implemented 
sh:filterShape and what it means in their applications. It seems to me 
that filters act quite differently from sh:and.

kc

>
> So if people continue to struggle with this feature, I'd be ready to
> drop it from the language. sh:filterShape is easy to take out on a short
> notice. Having said this, we already use sh:filterShape in practice in
> our products.
>
> Holger
>
>
>
> On 15/10/2016 6:45, Irene Polikoff wrote:
>> 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
>> <mailto: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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234
>>     skype: kcoylenet/+1-510-984-3600
>>
>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Sunday, 16 October 2016 21:18:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:37 UTC