- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 5 Nov 2016 13:44:00 -0700
- To: public-data-shapes-wg@w3.org
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. 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!) 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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Saturday, 5 November 2016 20:44:37 UTC