Re: shapes-ISSUE-192 (Are focus nodes shapes?): Should focus nodes be of type sh:Shape? if not, then what?

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

Received on Wednesday, 19 October 2016 22:14:03 UTC