Re: Question on Handling of Ill-formed Shapes Graphs

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.

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 Thursday, 16 February 2017 23:04:29 UTC