Re: Question on Handling of Ill-formed Shapes Graphs

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

Received on Sunday, 19 February 2017 22:58:59 UTC