Re: Question on Handling of Ill-formed Shapes Graphs

>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:29:08 UTC