Re: shapes-ISSUE-192 (Are filters shapes?) - final questions

On 6/11/2016 6:44, Karen Coyle wrote:
>
>
> On 11/3/16 4:51 PM, Holger Knublauch wrote:
>>
>>
>> On 4/11/2016 2:20, Karen Coyle wrote:
>>>
>>>
>>> On 11/2/16 10:53 PM, Holger Knublauch wrote:
>>>>
>>>>
>>>> On 3/11/2016 14:36, Karen Coyle wrote:
>>>>>
>>>>>
>>>>> On 11/2/16 5:20 PM, Holger Knublauch wrote:
>>>>>>
>>>>>>
>>>>>> On 3/11/2016 0:48, Karen Coyle wrote:
>>>>>>> As decided at the meeting:
>>>>>>>
>>>>>>> On 10/28/16 9:39 AM, Karen Coyle wrote:
>>>>>>>> *QUESTION 1: What does it mean for a target to be "processed" as a
>>>>>>>> value? It's the term "processed" here that is problematic.
>>>>>>>> Perhaps an
>>>>>>>> example would help, and then we could tweak the language.
>>>>>>>
>>>>>>> Proposed: The target of a shape that is the value of another shape
>>>>>>> MUST be ignored.
>>>>>>
>>>>>> This isn't correct. This would also mean that target must be ignored
>>>>>> here:
>>>>>>
>>>>>> ex:PersonShape
>>>>>>     sh:property [
>>>>>>         sh:predicate ex:address ;
>>>>>>         sh:shape ex:AddressShape ;
>>>>>>     ] .
>>>>>>
>>>>>> ex:AddressShape
>>>>>>     sh:targetClass ex:Address .
>>>>>>
>>>>>> I have tried to explain before that this is a matter of context,
>>>>>> and it
>>>>>> only is ignored at validation time, not always.
>>>>>
>>>>> The spec has to define that context, and so far it doesn't. Please
>>>>> show an example of a target that would be ignored, and I will try to
>>>>> find appropriate wording.
>>>>
>>>> See the example above. Yes, we could put an elaborated example like 
>>>> this
>>>> together with example instance data and validation results. The 
>>>> problem
>>>> is that this is coming a bit early in the document - why should the
>>>> first example about targets be one that ignores targets. I also 
>>>> honestly
>>>> don't think such a corner case deserves so much space. I think we 
>>>> could
>>>> even delete the "Targets MUST be ignored..." paragraph because it
>>>> already follows as an implication from elsewhere. See the first 
>>>> sentence
>>>> "A target provides *one way* to specify potential focus nodes...". 
>>>> Other
>>>> ways include explicitly referencing a shape via sh:shape. So what 
>>>> about
>>>> deleting the paragraph and adding something along the lines of what 
>>>> Eric
>>>> suggested last night, to elaborate on other ways of finding focus 
>>>> nodes
>>>> such as API calls?
>>>
>>> Holger, you have misunderstood my question. I am not asking for such
>>> an example to be added to the spec. I am asking for the example so
>>> that I can consider better wording. You say that the example above is
>>> one that should NOT be ignored. I am asking for an example of one that
>>> SHOULD be ignored, that illustrates the context you have cited.
>>
>> In the example above, the sh:targetClass statement is
>>
>> - ignored if the AddressShape is reached as part of the sh:shape 
>> statement
>> - not ignored if the whole data graph is validated, i.e. the "standard
>> way" of using SHACL
>
> Neither this "context" nor what the phrase "standard way" represents 
> are defined in the spec. This seems to go beyond what is defined in 
> SHACL core, which is a language but does not include processing 
> instructions that would govern the re-use or context for individual 
> shapes. I don't find anything that would explain how, given the SHACL 
> shape above, AddressShape would be reached via any route that is not 
> part of the sh:shape statement. If there is a way, then we have 
> something missing from the spec. if this information is essential, 
> then additions to the spec are needed that would clarify the meaning.

AddressShape is reached because validation of the data graph results in 
validating each node that is in any target statement (see beginning of 
section 3). The triple ex:AddressShape sh:targetClass ex:Address means 
that it will be reached for any instance of ex:Address.

>
> As for including alternate entries to constraints, such as APIs, that 
> might be resolvable with an issue. I'm hoping that it would be 
> sufficient to have a statement in or around where focus nodes and/or 
> constraints are defined to state that constraints act on focus nodes 
> with no regard to how those nodes were determined; and that focus 
> nodes can be defined with mechanisms that are external to the shapes 
> graph. (Approximate wording!)

This was the intention of the last bullet item in

http://w3c.github.io/data-shapes/shacl/#dfn-focus-node

  * specified as input to the SHACL processor for validating specific
    nodes from thedata graph
    <http://w3c.github.io/data-shapes/shacl/#dfn-data-graph>against the
    shape

This covers the cases in which targets are bypassed.

Holger

>
> kc
>
>>
>> So if the shape is reached via sh:shape then the system does not test
>> whether the given value of ex:address is also an instance of ex:Address
>> (class). It could for example also be an untyped resource. sh:target
>> never behaves like a constraint. (filterShape does).
>>
>> HTH
>> Holger
>>
>>
>>>
>>> kc
>>>
>>>>
>>>> Anyway, now that I have given you an example, can you now rephrase the
>>>> paragraph about ignoring the target?
>>>>
>>>> Overall, we seem to continue to struggle with a different mindset 
>>>> about
>>>> the role of the spec here. I believe you want it to be longer and more
>>>> instructive, while currently it's rather compact and just mentions the
>>>> facts. You do not like this, but my viewpoint remains that this 
>>>> document
>>>> is not a tutorial.
>>>>
>>>> Holger
>>>>
>>>>
>>>>
>>>>>
>>>>> kc
>>>>>
>>>>>>
>>>>>>>
>>>>>>> (Alternate: The target *in* a shape... - I'm not sure what
>>>>>>> language we
>>>>>>> are using for the various components of shapes. It could be "The
>>>>>>> target that is a component of a shape ..." Any of those would be ok
>>>>>>> with me as long as we are consistent.)
>>>>>>>
>>>>>>>>
>>>>>>>> *QUESTION 2: Does "are" here mean "MUST"? (This is a question
>>>>>>>> throughout
>>>>>>>> the document, actually, wherever "are" is used in this way.
>>>>>>>> Perhaps we
>>>>>>>> can decide once for all.)
>>>>>>>
>>>>>>>
>>>>>>> Yes, MUST must be used here.
>>>>>>
>>>>>> I have switched to MUST.
>>>>>>
>>>>>> https://github.com/w3c/data-shapes/commit/06cd60457ec3448d7ca578c4aa3df324bea846f0 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Could we close this ticket now?
>>>>>>
>>>>>> Holger
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>