Re: implementation of core SHACL (using proposed syntax)

Here is an extract from my implementation notes that describes how result sets
can be augmented and combined to produce detailed validation results.


The result sets contain bindings for the following variables:
  Variable SHACL predicate  description
  parent          the node that was traversed to get
       to the focus node, if any
  this  sh:focusNode  focus node
  PS  sh:sourceShape  identifier for shape that produced the result
  CS     identifier for embedded shape, if any
  subject sh:subject  usually focus node of violation
  predicate sh:predicate  property or path involved in violation
  object sh:object
  severity sh:severity  severity of result
  shape     identifier for top-level shape (probably not needed)
  component sh:sourceTemplate component property that produced the result
  message sh:message  a human readable message

Identifiers for shapes are the node itself if the shape is an IRI and a
unique identifier for shapes that are blank nodes.  Note that for inverse
properties, the subject variable is the object of the triple that produced
the violation and the object variable is the subject of the triple.

A node validates against a shape if there is no solution in the result set
with the variable this bound to the node or unbound, the variable PS
bound to the identifier for the shape, and the variable severity bound to
sh:Violation.

The SHACL validation results graph can be constructed by first creating a
blank node for each solution in the result set and adding triples with it as
subject as above.  For solutions that have the CS variable bound a sh:detail
triple is added for each other solution that has its PS variable bound to
the CS binding in this solution and the focus node of this solution as its
binding for the parent variable.  This triple has the node for this solution
as its subject and the node for the other solution as its object.



On 04/17/2016 07:07 PM, Holger Knublauch wrote:
> On 14/04/2016 5:29, Peter F. Patel-Schneider wrote:
>> On 04/13/2016 02:49 AM, Peter F. Patel-Schneider wrote:
>>>
>>> On 04/12/2016 10:40 PM, Holger Knublauch wrote:
>>>> On 13/04/2016 1:11, Peter F. Patel-Schneider wrote:
>>>> [...]
>>>> This also confirms two limitations of this single-query-transformation
>>>> approach (we had discussed this before):
>>>> - inability to generate nested validation results
>>>> - inability to handle recursion
>>>> The current design uses sh:hasShape which doesn't have these limitations.
>>>>
>>>> Holger
>> I just made a minor modification to the way that validation results are
>> combined to allow for nested validation results.
>>
>> peter
>>
> 
> Hi Peter,
> 
> you have made me curious here. Would you mind providing some details or an
> example? I assume we are talking about a case such as a sh:valueShape that
> fails, and its result object should point to other validation results for each
> value that does not match the shape, via sh:detail. So I was expecting to find
> some reference to sh:detail in your implementation.
> 
> Thanks
> Holger
> 
> PS: Apologies in advance for not responding to the other open email threads
> yet - I am trying to focus on updating my implementation and the advanced
> sections of the spec to the metamodel 3 draft. I will get back to the other
> emails once this block of work is completed.
> 
>

Received on Monday, 18 April 2016 03:37:52 UTC