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

On 25/10/2016 2:13, Karen Coyle wrote:
>
>
>
>
> On 10/20/16 10:29 PM, Holger Knublauch 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.
>
> Then I misunderstood what you meant when you said:
>
> "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) 
>
>
> Perhaps you were referring to the subclass relationship between 
> sh:Shape and sh:Constraint?
>
>>
>> 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.
>
> For reference, sh:filterShape is defined thus:
>
> sh:filterShape
>     a rdf:Property ;
>     rdfs:label "filter shape" ;
>     rdfs:comment """
>         This property links a constraint to shapes that the focus 
> nodes need to fulfill before the constraint is evaluated.
>         """^^rdf:HTML ;
>     rdfs:domain sh:Constraint ;
>     rdfs:range sh:Shape ;
>     rdfs:isDefinedBy sh: ;
>
> The range of sh:filterShape is sh:Shape. However ...
>
> "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) or, filter shapes 
> (sh:filterShape)." (2.1)
>
> And here's an example of the formal definition of a target:
>
> sh:targetObjectsOf
>     a rdf:Property ;
>     rdfs:label "target objects of" ;
>     rdfs:comment """
>         Links a shape to a property.
>         The shape must be satisfied by all objects of triples that 
> have the given property as its predicate.
>         """^^rdf:HTML ;
>     rdfs:domain sh:Shape ;
>     rdfs:range rdf:Property ;
>     rdfs:isDefinedBy sh: ;
>
> First, in the above description of targets, I'm not clear what 
> "referenced shape in parameters of shape-based constraint components" 
> means. When is a shape "referenced"? ("Referenced" is not defined.) 
> Are these parameters the same as the constraint parameters defined in 
> 2.3? 

I have clarified in the spec that they are values of these parameters.

> Is there any case when a target is not ignored when in a sub-graph of 
> a sh:filterShape?

I don't understand this sentence. What is a sub-graph of sh:filterShape?

>
> Second, in the examples, in every case sh:filterShape has a blank node 
> as its object, and that blank node has sh:property as its predicate. 
> (sh:property is of type sh:Shape) If there are other possibilities, it 
> would be good to define them and show them in examples. If this is the 
> only possibility, it might be best to describe sh:filterShape in this 
> way, rather than saying what it isn't.

In my opinion, it will be more common than not to use blank nodes for 
these filter shapes. We only have two examples of filterShape right now. 
I think it would be a hint in the wrong direction if we include an 
example where a filter shape is also a "global" IRI resource. More 
generally, we have plenty of features that are only described using 
either bnodes or IRIs. We cannot print every combination. I think since 
we are nowhere excluding IRIs, the reader can hopefully infer that these 
nodes may be IRIs too.

>
> Third, it would be good to describe this exception where 
> sh:filterShape is defined, not elsewhere in the document. The 
> information about a property needs to be found at or very near the 
> definition of the property. Obviously it can be a forward reference, 
> but one can't count on users making the connection when information is 
> spread apart in the document.

Could you suggest a specific "diff"? I am unclear what you are referring 
to. For now, I have added the following sentence to the section on 
filter shapes:

---
Note that during the validation against filter shapes, the <a 
href="#targets">targets</a> of these filters are ignored.
---


>
> Fourth, this exception means that the RDF vocabulary does not describe 
> the actual range of sh:filterShape since the four target properties 
> that are excepted are indeed of type sh:Shape. Therefore, it would be 
> good to have clarity on what the relationship is between the RDF 
> vocabulary and the SHACL document. As an example, Dublin Core has a 
> concept of application profiles where an application can build on a 
> more general vocabulary, further refining values, setting 
> cardinalities, etc. SHACL Core is beginning to look a bit like such a 
> profile in relation to the RDF vocabulary. I'm not sure that works, 
> but it's worth a thought.

I cannot see an error in the RDF vocabulary. The range of sh:filterShape 
is sh:Shape, which means that RDFS-aware tools may infer that its values 
are instances of sh:Shape. I don't understand what you are referring to 
with regards to application profiles.

Latest change set:

https://github.com/w3c/data-shapes/commit/119775926511c3e90b4a39df8bb8abea8a4b4eeb

Holger


>
>
>>
>> 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.
>
> I don't think that XML functionality is relevant to RDF vocabularies.
>
>>
>> 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 see this as only worsening the problem of consistency and conformance.
>
> kc
>
>>
>> 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 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Tuesday, 25 October 2016 06:08:25 UTC