RE: Question on Handling of Ill-formed Shapes Graphs

Hello Holger,

Apologies if I stirred up a hornet's nest... I thought it would be fairly uncontentious. 

On Thursday, February 16, 2017 10:55 PM, Holger Knublauch [mailto:holger@topquadrant.com] wrote:

> 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.

I don't quite grasp this. The way I read your explanation, it would mean that a SHACL implementation is not required to implement all the syntax rules. That is a contradiction to the conformance criteria [1] for "SHACL Core processors as processors that support validation with the SHACL Core Language" which in my reading means that a conformant SHACL Core processor MUST support all syntactic rules in the SHACL Core Language (and similarly a conformant SHACL-SPARQL processor MUST support all syntactic rules in the SHACL-SPARQL Language).

To me Peter's suggestion to split between SHACL Core and SHACL-SPARQL syntax checking sounds sound at the _conceptual_ level. I do understand the point though, that it lowers the barrier of entry at the _technical_ level and particularly the formal process.
 
> 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.

Thank you, this is the kind of case I was looking for.

What worries me with the current text is that a user could be made believe that if the result of a SHACL validation process is undefined when the shapes graph is ill-formed the processor could in fact return sh:conforms true. One solution could be to add the requirement that if a SHACL processor does not produce a failure in the case of an ill-formed graph, it MUST NOT produce a result with the value sh:conforms true. (I. e. the default result of such an processor must be sh:conforms false). 

> 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.

If that makes the validation of the shapes graph more efficient, it certainly would be something to pursue.

> Hope this clarifies it.

Yes, at least partly.

Thanks,

Lars
 
> 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 14:59:28 UTC