- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 30 Jan 2016 16:48:41 +1000
- To: public-data-shapes-wg@w3.org
(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. https://github.com/w3c/data-shapes/blob/gh-pages/shacl/shacl-vocab-hk.ttl See also https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Nov/att-0165/SHACL-Metamodel-Draft-2.png HTH Holger
Received on Saturday, 30 January 2016 06:49:14 UTC