ISSUE-211: Should we turn sh:property and sh:sparql into constraint components?

One aspect where the design proposed by Dimitris is nicer is that 
everything is uniformly treated as a constraint component. So not only 
sh:minCount is backed by a constraint component but also sh:property and 
sh:sparql. I think this would be a worthwhile way of defining them and 
the cost of this change is low. I cannot think of changes this would 
have for users.

So basically, the new sh:PropertyConstraintComponent would be defined to 
perform validation of the focus node against all property constraints 
(the values of sh:property). All resulting validation results would be 
copied into the results graph. (This is BTW different from sh:shape, 
where the nested results are *not* becoming top-level results but only 
values for sh:detail).

And sh:SPARQLConstraintComponent would be defined to execute the given 
SPARQL query and use the resulting validation results.

After this change, we can simplify the definition of validation to be 
about all components of the given constraint.

How does this sound (as a belated compromise)?

(I did not raise a formal issue yet but if there is support then we can 
for example make an addendum to the resolution of ISSUE-211).

Holger

Received on Friday, 16 December 2016 03:29:57 UTC