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

On Fri, Oct 21, 2016 at 8:29 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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

I would support this proposal.
What is the status / support for filter shapes in ShEx?


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


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