- From: Irene Polikoff <irene@topquadrant.com>
- Date: Thu, 16 Feb 2017 21:44:20 -0500
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
I read the process description as a requirement to provide technical rationale - this has been done in the previous e-mail. I do not see where this description says that the rationale must include pointers to all discussions that took place on a particular topic over the course of the working group activity. It would seem to me that such a requirement would be extremely burdensome and unrealistic. Irene > On Feb 16, 2017, at 9:28 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote: > >> From World Wide Web Consortium Process Document, 1 September 2015 > https://www.w3.org/2015/Process-20150901/ > > In the context of this document, a group has formally addressed an issue when > it has sent a public, substantive response to the reviewer who raised the > issue. A substantive response is expected to include rationale for decisions > (e.g., a technical explanation, a pointer to charter scope, or a pointer to a > requirements document). The adequacy of a response is measured against what a > W3C reviewer would generally consider to be technically sound. > > So it is part of the job of the working group to justify their responses to > commenters. > > Peter F. Patel-Schneider > Nuance Communications > > > On 02/16/2017 05:06 PM, Holger Knublauch wrote: >> I believe the most recent discussion on this topic happened in this meeting: >> >> https://www.w3.org/2017/01/25-shapes-minutes.html >> >> Sorry I am unable to sift through all past meeting minutes or the thousands of >> emails that this WG has produced. I still do have a day job and plan to keep >> it. You are welcome to use internet search or the archives yourself. >> >> Holger >> >> >> On 17/02/2017 10:54, Peter F. Patel-Schneider wrote: >>> Please provide a pointer to this discussion and any relevant resolutions. >>> >>> Peter F. Patel-Schneider >>> Nuance Communications >>> >>> >>> On 02/16/2017 04:01 PM, Holger Knublauch wrote: >>>> >>>> On 17/02/2017 9:03, Peter F. Patel-Schneider wrote: >>>>> Some of the syntax requirements for constructs in SHACL-SPARQL hinge on >>>>> whether a string is a syntactically correct SPARQL SELECT or ASK query and >>>>> are >>>>> thus very complex. There is no distinction in SHACL between these syntax >>>>> requirements and the syntax requirements for constructs in SHACL Core so a >>>>> SHACL Core processor would need to implement a SPARQL syntax checker. >>>>> >>>>> However, I don't see any good reason why a SPARQL Core processor needs to >>>>> consider the syntactic validity of any SHACL-SPARQL constructs at all. A >>>>> SHACL >>>>> Core processor, by design, doesn't do anything with these construct so there >>>>> is no benefit for a SHACL Core processor to do this checking. >>>>> >>>>> So all that a SHACL Core processor really should be doing as far as syntax >>>>> testing is concerned is checking the SHACL Core constructs for syntactic >>>>> validity. This appears to be fairly easy - the hardest part is probably >>>>> checking for valid SHACL property paths. But even if checking the syntactic >>>>> validity of a SHACL property path is not so easy, a SHACL Core processor is >>>>> going to have to do much of the checking for syntactic validity when it uses >>>>> the list. >>>>> >>>>> It thus seems to me that SHACL Core processors should be required to check >>>>> for >>>>> syntactic validity of SHACL Core constructs and should completely ignore >>>>> SHACL-SPARQL constructs. >>>> The WG had already discussed this topic at length and come to the conclusion >>>> outlined in my email, for the reasons outlined in my email. >>>> >>>> Holger >>>> >>>> >>>> >>>>> Peter F. Patel-Schneider >>>>> Nuance Communications >>>>> >>>>> >>>>> >>>>> >>>>> On 02/16/2017 01:54 PM, Holger Knublauch wrote: >>>>>> Hi Lars, >>>>>> >>>>>> there are two major reasons for the current wording, basically due to the >>>>>> complexity of the many syntax rules: >>>>>> >>>>>> 1) If we were to make it a MUST then each SHACL implementation would have to >>>>>> implement all the syntax rules, and we as the WG would need to define test >>>>>> cases for all kinds of invalid structures. The SHOULD lowers the barrier of >>>>>> entry and the formal process issues significantly. >>>>>> >>>>>> 2) It would require validation (for well-formedness) of the shapes graph and >>>>>> this is a very expensive operation. In many scenarios such as interactive >>>>>> data >>>>>> entry tools, the shapes graph is identical to the data graph (or at least is >>>>>> part of the imports closure). If you make an edit, then the shapes may >>>>>> become >>>>>> invalid. This means that a validator would have to perform checking of the >>>>>> shapes before each validation, and this is prohibitively expensive in cases >>>>>> like form validation in real time, for each instance. >>>>>> >>>>>> Having said this, many syntax rules can be expressed in SHACL itself. The >>>>>> expectation of the WG is that a meta-schema for SHACL will emerge (e.g. >>>>>> as an >>>>>> open source project) outside of the W3C process. Not everything needs to be >>>>>> done by the WG or the spec. >>>>>> >>>>>> Hope this clarifies it. >>>>>> Holger >>>>>> >>>>>> >>>>>> On 16/02/2017 19:36, Svensson, Lars wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Section 3.4.2 [1] states that if a shapes graph is ill-formed, the SHACL >>>>>>> processor SHOULD produce a failure. Why is that a SHOULD and not a MUST? Or >>>>>>> put differently: In which cases would it be acceptable for a processor not >>>>>>> to produce a failure when processing an ill-formed shapes graph? >>>>>>> >>>>>>> [1] https://w3c.github.io/data-shapes/shacl/#ill-formed-shape-graphs >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Lars >>>>>>> >>>>>>> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** >> >
Received on Friday, 17 February 2017 02:44:55 UTC