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

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 20:42:01 UTC