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

Re: proposed set of SHACL tests

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 15 Jan 2016 15:08:59 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <56987EEB.8060209@topquadrant.com>
Peter,

I did run a copy of your tests and noticed that my engine currently has 
trouble when a sh:Shape is a blank node (I will investigate later). If 
you turn the shape in simpleShape.ttl into a URI node for now, you will 
only have 2 remaining test failures. Those are due to the (already) 
discussed issue that the validation is performed over the shape 
definitions, and the SHACL graph currently requires sh:class to point at 
classes.

HTH
Holger

PS: If you are still having github access issues, maybe talk to Eric?


On 12/01/2016 3:16 AM, Peter F. Patel-Schneider wrote:
> On 01/10/2016 07:14 PM, Holger Knublauch wrote:
>> Hi Peter,
>>
>> thanks for playing with the test framework. I am still catching up on a number
>> of fronts and may not have time to look into the details this week. A quick
>> scan through your results indicates
>>
>> - My current test framework also validates the shape definitions. A symptom of
>> this is that, for example, values of sh:class are expected to be instances of
>> rdfs:Class. The idea in my API is that this schema-level testing can be
>> switched off using the "filtered" argument of
>> ModelConstraintValidator.validateModel. ValueTestClass calls this with false,
>> i.e. everything will be validated including shapes.
> The problem is that these results look just like data validation results,
> which is problematic in my view.
>
>> - Inferencing is switched off by default, as defined by the spec. So you
>> should not expect rdfs:range and rdfs:domain to impact validation.
> Well that was my expectation.  However it does not appear to be the case.  In
> particular, the use of a node as the target of an rdf:type link appears to
> make the node be an instance of rdfs:Class.
>
> peter
>
>
Received on Friday, 15 January 2016 05:09:39 UTC

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