- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Tue, 15 Dec 2015 10:26:15 -0500
- To: public-data-shapes-wg@w3.org, 564F19F6.9080802@topquadrant.com
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 ... " .
-- Arthur
Received on Tuesday, 15 December 2015 15:26:42 UTC