Re: Updated proposal to close ISSUE-51 based on Turtle file in ISSUE-51 branch

Here is a link to the (roughly 200 highlighted) lines that matter:

https://github.com/w3c/data-shapes/blob/ISSUE-51/shacl/shacl.shacl.ttl#L321-L517

This will hopefully make reading more manageable. All URIs have 
rdfs:comments attached to them.

On 8/4/15 10:29 AM, Peter F. Patel-Schneider wrote:
> This resolution points to a document with 1966 lines.  The summary is lacking
> details.
>
> Please provide the relevant definitions so that I can determine what is going
> on.
>
> In particular, it appears that failure results encompass both non-logical
> (communications) issues and logical (recursion) issues.  I don't see why
> recursion issues are not a kind of validation failure.

See my parallel thread on ISSUE-76, where I asked whether recursion 
errors may even just be "False" results. This is probably a separate 
topic altogether.

I am not sure how other WGs solve such a situation in which we need to 
start making partial changes without changing everything at once. The 
changes here are obviously just an intermediate step. But whether 
recursion errors are later moved into validation failures is something 
we can change at a later time - it would be a matter of changing their 
rdf:type from sh:Failure to sh:Severity.

Holger



>
> peter
>
>
> On 08/03/2015 05:18 PM, Holger Knublauch wrote:
>> Dimitris and I had some detailed discussions about ISSUE-51 and I believe we
>> have largely agreed on a revised design that I would like to propose to the
>> group:
>>
>> PROPOSAL: Close ISSUE-51 based on the design outlined in the Turtle file
>> https://github.com/w3c/data-shapes/blob/ISSUE-51/shacl/shacl.shacl.ttl
>>
>> Note that I did *not* yet update the textual companion documents because this
>> would be quite some work that I'd rather delay until we have a general agreement.
>>
>> Summary of changes:
>>
>> There are now three kinds of results:
>> - ValidationResults point at a severity level such as Warning and Error and
>> provide additional details about which triples were causing the violation
>> - FailureResults are unexpected situations such as unsupported recursion or
>> communication problems with a database ("sorry we could not process your
>> request")
>> - SuccessResults can be used to capture successful runs, for logging purposes
>>
>> It is easy to add new types of severity levels (which also carry an index so
>> that they can be ordered), and failure types. The design also makes it easy to
>> repurpose the severity levels for additional use cases such as accumulated
>> results.
>>
>> There were also various renamings and other minor clean ups. Nothing changes
>> for the syntax of the SELECT queries.
>>
>> Holger
>>
>>

Received on Tuesday, 4 August 2015 00:52:11 UTC