Re: more sloppiness in the SHACL document

On 12/13/2016 09:17 AM, Karen Coyle wrote:
> 
> 
> On 12/5/16 10:56 PM, Peter F. Patel-Schneider wrote:
[...]
>> Given a focus node f, an optional value node v, a shape s, an optional path
>> <p,P>, an optional severity e, and a constraint component C is a SHACL results
>> graph
>> - containing all the triples in P
>> - where p is a SHACL property path in the graph
>> - and which has exactly one top-level validation result n
>>   - whose value for sh:focusNode in the graph is f
>>   - whose value for sh:resultPath in the graph is p, if p is present,
>>     otherwise there is no value for sh:resultPath in the graph
>>   - whose value for sh:value in the graph is v, if v is present,
>>     otherwise there is no value for sh:value in the graph
>>   - whose value for sh:sourceShape in the graph is s
>>   - whose value for sh:sourceConstraintComponent in the graph is c
>>   - whose value for sh:resultSeverity in the graph is e, if e is present,
>>     otherwise sh:violation
>>
> 
> This may need two more changes: 1) sh:resultMessage isn't listed here and 2)
> values for sh:resultSeverity and sh:resultMessage can be either input from the
> shapes graph as sh:severity and sh:message OR can be generated by the SHACL
> engine. I believe the rules for generation of sh:message are found in the
> extension section 5.4. I'm not sure what happens in a core implementation if
> no sh:severity or sh:message is present.
> 
> kc

Yes, sh:resultMessage isn't handled in this account.  It would need to be added.

sh:resultSeverity comes from the shape, via its severity.  Severity defaults
to sh:Violation.  I think that that covers all the bases.

peter

Received on Tuesday, 13 December 2016 18:12:43 UTC