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

On 8/5/2015 2:51, Peter F. Patel-Schneider wrote:
> Severities appear to be both symbolic (sh:Info, sh:Warning, ...)  and
> numeric (sh:severityIndex).  Do both matter?

My suggestion is to use the symbolic names for users, e.g. when they 
invoke the engine ("I only want Error-level and above"). The severity 
index is used internally because the system can otherwise not know that 
Info is less critical than Warning. The specific indices are only 
relevant to people who want to inject their own severity levels.

>    Can there be two severities with the same sh:severityIndex?

Yes, in theory.

>
> Failures cover both control issues, e.g., illegal syntax, and logical
> issues, e.g., recursive loops.  (This is assuming that (negative) recursion
> is syntactically valid but that encountering a recursive loop produces a
> failure.)  I think that these two need to be separated.
>
> Results cover both failures and violations, and more.  All results are
> reported by constructing an RDF graph containing information about results.
> I think that constructing an RDF graph is too heavy-weight for reporting
> results.

The RDF graph is just the way how we specify it in the spec. Actual 
implementations may instead instantiate Java Objects, fill a spreadsheet 
or whatever.

Holger


>
> I think that a simpler approach is called for.  If there needs to be complex
> processing then it is better to do that outside of SHACL.
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>
> On 08/03/2015 05:51 PM, Holger Knublauch wrote:
>> 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 Wednesday, 5 August 2015 00:39:25 UTC