Re: Question on Handling of Ill-formed Shapes Graphs

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 00:02:15 UTC