Re: Question on Handling of Ill-formed Shapes Graphs

The spec says that a SHACL Core processor must be able to validate data against any shape in the shapes graph that is expressed using SHACL Core and is well formed. 

The spec does not place a conformance requirement on the SHACL Core processor with respect to the shapes that are ill formed. For example, the processor could silently ignore such a shape and move on with validating data against all the well formed shapes in the shapes graph. It could also ignore it and move on with other validations, but issue a warning that one of the shapes was ill formed. Or it could stop any further processing and perform no validation against the shapes graph if it contains an ill formed shape. Which option to take is left to implementations. The spec doesn’t mandate anything.

Similarly, for SHACL-SPARQL.

Irene

> On Feb 19, 2017, at 5:58 PM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> 
> 
> On 18/02/2017 0:58, Svensson, Lars wrote:
>> 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).
> 
> That's not how I would read the conformance section. SHACL Core is explicitly not required (via MUST) to do syntax checking - so compliant processors merely MUST support validation following these rules.
> 
>> 
>> 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).
> 
> The Shapes WG has not defined an API for SHACL. This is significant, because it does not prescribe a programmatic interface for applications. Each implementation will offer its own interfaces and different parameters. I expect that implementations will offer flags to indicate what levels of features should be activated. In TopBraid's engine, we have a "flag" (via a SHShape filter) that activates or deactivates checking of the shapes themselves.
> 
> As a result of this, the caller of the API already knows whether it will perform shapes validation or not. Therefore I don't see why we would need to explicitly report this back.
> 
> Overall I believe the usual workflow will be that people develop their shapes and use a meta validator until the shapes graph is valid. Only then they put it into practice, with a set of shapes that are already tested for correctness. There is no need to test this over and over again.
> 
> Regards,
> Holger
> 
> 
> 
>> 
>>> 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 ***