W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 2016

Re: implementation of core SHACL (using proposed syntax)

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Sun, 17 Apr 2016 20:37:22 -0700
To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
Message-ID: <57145672.4010506@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:31 UTC