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

Re: implementation of core SHACL (using proposed syntax)

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 21 Apr 2016 19:29:31 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <57189D7B.6080504@topquadrant.com>
Hi Peter,

I still don't understand how this works. Could you print some SPARQL 
that is being generated?

What I don't understand is that if you turn sh:valueShape into nested 
validation calls, then how do the inner result sets ever get turned into 
validation result resources? If you have somehow solved this, then why 
does the same approach not work for recursion?

(This may be obvious to you as the implementer, but is not clear to me)


On 18/04/2016 13:37, Peter F. Patel-Schneider wrote:
> 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 Thursday, 21 April 2016 09:30:08 UTC

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