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

The description of the ISSUE-192 now states

Filter shapes are currently defined as a subclass of sh:Shape

which is not correct. There is no subclass of sh:Shape in SHACL.

In general, I don't understand what this issue is about. I see no 
problem with the fact that certain properties of a resource are ignored 
depending on the context. In this case, sh:targetXY are ignored if a 
shape is evaluated as a filter shape. The situation may have to be 
explained better, but I see no technical issue, and to me at least the 
current wording is quite clear.

XSD seems to have something very similar:

     https://www.w3.org/TR/xmlschema11-1/#xsi_type
https://www.liquid-technologies.com/xml-schema-tutorial/xsd-extending-types#xsi-type

The xsi:type attribute can be used by any XML "instance" document to 
explicitly state that a certain element (=node) has a certain type 
(=shape). This is despite the fact that the same XSD type may be 
referenced from other types within its own document. So in a sense, this 
is also overriding the default use of the given XSD type with a direct 
pointer.

On the comment that I gave earlier, that filter shapes introduce issues 
such as non-monotony: if anyone else sees this as a problem too, I would 
be happy to drop sh:filterShape and replace it with a flag sh:disabled 
true. The meaning of that would be that an engine would always return 
"valid" if a node is validated against a shape that is marked to be 
disabled. This covers our use case (of locally disabling certain shapes 
or constraints that happen to be imported) and would support scenarios 
where people want to temporarily switch off certain shapes or 
constraints during development without having to delete them.

Regards,
Holger


On 21/10/2016 5:16, Karen Coyle wrote:
> 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 
>>>
>>>
>>>
>>>
>>
>>
>