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

On 10/25/16 11:29 PM, Holger Knublauch wrote:
>
>
> On 26/10/2016 4:05, Karen Coyle wrote:
>>
>>
>> On 10/24/16 11:07 PM, Holger Knublauch wrote:
>>>
>>>
>>> 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: ;
>>
>> One other thing here that is a bit confusing is that sh:filterShape is
>> of domain sh:Constraint. However, it is in the section on shapes (2.)
>> which reads:
>>
>> Shapes
>> - Targets
>> - Filter shapes
>> - Constraints
>>
>> It may make more sense if filter shapes are placed under constraints
>> since they are often referred to in the text as performing a
>> "validation". Also, if constraints are not themselves shapes then I'm
>> not sure what unifies section 2.
>
> Yes that's not good. I have changed the title of section 2 to "Shapes
> and Constraints" to better indicate what the section is about. It could
> also be something like "Basic Concepts of SHACL".
>
>>
>> Note that the first sentence of filter shape (2.2) says that the
>> filter shape is a shape: "A filter is a shape in the shapes graph that
>> further refines the focus nodes in the data graph that are validated
>> against a constraint or all the constraints of a shape."
>
> Hmm well, that's formal language - I don't see a mistake but it's not
> very readable. This is the general conflict that we have as editors:
> some people tell us they want it more formal and others tell us they
> want it more readable. It's not always possible to have both. If in
> doubt, I am afraid I'll have to stick with the formal language and leave
> the rest to other material. I welcome diffs with better prose.
>

It's not the language that is the problem - it's that it says that a 
filter is a shape, which I read as
sh:filterShape rdf:type sh:Shape

while the RDF says:

sh:filterShape rdf:type sh:Constraint


>>
>> (I admit to being thoroughly confused in this section.)
>>
>>
>>>>
>>>> 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.
>>
>> If I have understood this sentence:
>>
>> Targets are ignored when a shape is processed as a value of parameters
>> of shape-based constraint components (i.e. sh:shape), logical
>> constraint components (i.e. sh:or), or filter shapes (sh:filterShape).
>>
>> ... then I believe it can be said more clearly as:
>>
>> Targets MUST be ignored in the values of shape-based constraint
>> components (i.e. sh:shape), logical constraint components (i.e.
>> sh:or), or filter shapes (sh:filterShape).
>>
>> ("values" might be said as "value nodes" to get across the graph
>> nature of that)
>
> No this would not be correct. The key is the context. The targets are
> only ignored if it is being *processed* as a value. A shape may also be
> executed stand-alone, as an entry point into the validation.

So I think we need some different wording for "processed", but I need to 
think about that.

>
>>
>>>
>>>> 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?
>>
>> See clarification below.
>>
>>>
>>>>
>>>> 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.
>>
>> Sorry, I wasn't clear. My question is not about the blank node, but
>> the predicate - sh:property. Are other predicates possible? If so, it
>> would be good to show at least one other predicate as an example. As
>> we know, people assume a lot from examples.
>
> The values of sh:filterShape are shapes, so I hope it's clear that these
> shapes may use other constraint components beside sh:property. I
> disagree this needs to be repeated each time.

I didn't say anything about repeated - I just asked for one of the 
examples to show a different component.

kc

>
>>
>>>
>>>>
>>>> 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.
>>> ---
>>>
>>
>> "Targets as values of filter shapes MUST be ignored."
>> or
>> "When targets are values of filter shapes, they MUST not be
>> applied/MUST be ignored."
>>
>> ("are" is a statement of fact, not a directive.)
>
> See above, this would be incorrect.
>
>>
>>>
>>>>
>>>> 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.
>>
>> No, it's not an error. I was hoping, I suppose, for an RDF vocabulary
>> that could function as more of an explanation of SHACL, but I see that
>> is not the case. Because I find the text to be unclear, I was grasping
>> for clarity in the RDF vocab.
>
> The rdfs:comments in the RDF file had been written ages ago (mostly by
> Arthur). They may no longer reflect the current design. I will clean
> that up once we are getting closer. My plan would be to copy and paste
> agreed-upon sentences from the spec into these comments. Doing this
> right now would be just duplicate work.
>
> Holger
>
>
>
>>
>>
>> DC application profiles are described here:
>> http://dublincore.org/documents/profile-guidelines/
>>
>> and the formal definition (which was never really completed, but was
>> what Tom Baker and I described at the original shapes meeting) is here:
>>
>> http://dublincore.org/documents/dc-dsp/
>>
>> This is what motivated DC to participate in this group.
>>
>> kc
>>
>>
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 26 October 2016 12:59:06 UTC