- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 20 Oct 2016 12:16:11 -0700
- To: public-data-shapes-wg@w3.org
Yes, it was too late in a day when I was up at 5am. I'll edit the issue. Thanks, kc On 10/19/16 3:13 PM, Holger Knublauch wrote: > I think you are mixing up focus nodes and filter shapes. Could you rephrase? > > Holger > > > Sent from my iPad > >> On 20 Oct. 2016, at 6:41 am, RDF Data Shapes Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: >> >> shapes-ISSUE-192 (Are focus nodes shapes?): Should focus nodes be of type sh:Shape? if not, then what? >> >> http://www.w3.org/2014/data-shapes/track/issues/192 >> >> Raised by: Karen Coyle >> On product: >> >> Focus nodes are currently defined as a subclass of sh:Shape and are referred to in the document as shapes. >> >> In the abstract syntax, this looks like: >> >> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], >> constraints:Set[Test] >> >> Given that sh:filterShape has a range of sh:Shape, the logical conclusion here is that a filter can theoretically have targets, filters, and constraints. >> >> However, the document says this in 2.1 Targets: >> >> "Targets are ignored when a shape is processed as a referenced shape in parameters of shape-based constraint components (i.e. sh:shape), logical constraint components (i.e. sh:or), filter shapes (sh:filterShape) or, for SHACL Full, in the evaluation of the sh:hasShape SPARQL function." >> >> I interpret this as meaning that range of sh:filterShape does not have the same qualities as the class sh:Shape. If this is the case then this doesn't follow the RDF definition of class membership. >> >> Holger said this in an email: >> >> "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." >> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0085.html >> >> Karen suggested that filters could be retained as their own "beast" by defining a new class (sh:Filter) type sh:Filter would take only constraints as an object. >> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0072.html >> >> However, now that sh:Shape is a subclass of sh:Constraint, the range of sh:Constraint is pretty much everything, so there isn't a class that can be used in a more narrow sense. >> >> Irene said: >> "<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.>" >> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0082.html >> >> >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Thursday, 20 October 2016 19:16:40 UTC