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

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.

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

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

Received on Thursday, 3 November 2016 16:21:10 UTC