W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > February 2017

Re: Question on Handling of Ill-formed Shapes Graphs

From: Irene Polikoff <irene@topquadrant.com>
Date: Thu, 16 Feb 2017 21:44:20 -0500
Cc: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Message-Id: <FAD97485-BC52-4F20-BEF8-691DD6EE9F59@topquadrant.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC