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

Re: ISSUE-95: Proposal for model simplifications

From: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 30 Jan 2016 16:48:41 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <56AC5CC9.2010208@topquadrant.com>
(Warning, old thread again)

On 16/12/2015 1:26 AM, Arthur Ryman wrote:
> Holger,
> I've had a  further thought about simplifications based on our Skype
> conversation. You raised the concern that the form of the SPARL query
> depends on where it is used. I was going to look into how we could
> wrap a core SPARQL definition so it could be used in all three
> contexts - NodeConstraint, PropertyConstraint,
> InversePropertyConstraint. A simpler approach suggested itself. We
> could use three different properties with the definition. This has the
> advantage that is cuts down the number of classes by a factor of three
> and avoids repeating the parameter information.
> Use:
> sh:nodeSparql for sh:NodeConstraint
> sh:propertySparql for sh:PropertyConstraint
> sh:inversePropertySparql for sh:InversePropertyConstraint
> The presence of these properties indicate where the assertion can be used.
> e.g. for a custom assertion that can be used in all three types of constraint:
> ex:MyAssertion rdfs:subclassOf sh:Assertion ;
>      sh:parameter ex:myParameter ;
>      sh:nodeSparql "SELECT ... " ;
>      sh:propertySparql "SELECT ... ";
>      sh:inversePropertySparql "SELECT ... " .

My current draft uses something similar. The ConstraintTypes (e.g. 
sh:MinCountConstraint) have three properties pointing at so-called 
sh:Validators (sh:propertyValidator, sh:inversePropertyValidator, 
sh:nodeValidator). The validators then hold the SPARQL queries or are 
simply functions returning a boolean.


See also


Received on Saturday, 30 January 2016 06:49:14 UTC

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