- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 8 Jun 2016 13:56:35 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
In [1] Peter argues that there should only be a single SPARQL query per constraint component because this would minimize the places where bugs can be introduced and therefore reduce development costs. He started that topic directly after his message [2] where he found out that in order to make all constraint components applicable in all three contexts, he would actually *increase* development costs because a lot of potentially duplicate code would need to be written. In [3] I have enumerated how many cases would actually be affected by this. Having investigated this a bit further, I believe if our motivation is indeed to reduce development costs, then a much simpler solution already exists, which does not sacrifice the flexibility that is required (as argued by myself and Dimitris) to implement cases like sh:hasValue. All we would need to do 1) Introduce generalized validators for path-based constraints (property/inverseProperty/path) 2) Forget about the idea of making all constraint component applicable everywhere. To back this up, we can look at the Core vocabulary again. While I cannot say how representative that selection of constraint components is, it may at least give some ballpark figures. Total: 29 Constraint Components - 17 of them can be implemented with a single ASK validator, for all cases. - 5 of them would be covered by a single path validator: - sh:hasValue - sh:maxCount - sh:minCount - sh:qualiMaxCount - sh:qualiMinCount - 3 of them are only applicable to a single context anyway: - sh:closed - sh:equals - sh:uniqueLang - the 4 remaining ones only require separate validators right now because of the error handling (?failure) - sh:shape - sh:and - sh:or - sh:not So: from the 29 components, 25 already have only one validator. The other four are probably special cases because they are fairly low-level, and even for them it would be quite easy to have a single validator only, by introducing an ASK-like mechanism that can also handle failures. Given this, I have no idea what problem we are trying to solve here. The "problem" only arose because of the desire to make all constraint components apply everywhere. The ASK validators and (assuming we put them into the language) path validators solve all other cases. HTH Holger [1] https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0008.html [2] https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0003.html [3] https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0009.html
Received on Wednesday, 8 June 2016 03:57:10 UTC