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

Re: Question on Handling of Ill-formed Shapes Graphs

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 17 Feb 2017 11:06:08 +1000
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-shapes@w3.org
Message-ID: <08d54f37-8957-cb28-3268-9e5146dae9c4@topquadrant.com>
I believe the most recent discussion on this topic happened in this meeting:


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.


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 01:06:46 UTC

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