- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sun, 5 Jun 2016 12:09:07 +1000
- To: public-data-shapes-wg@w3.org
On 5/06/2016 4:57, Karen Coyle wrote: > > > On 6/3/16 5:14 PM, Holger Knublauch wrote: >>> Having a single implementation of each constraint component would >>> actually >>> reduce development costs. Ideally, this single implementation would >>> be as >>> simple as the ask validators that implement many constraint components. >>> Consider, for example, sh:minCount whose implementation should be very >>> little more than "HAVING ( COUNT (DISTINCT ?value) < ?minCount )". >> >> Yes, if this were possible then this would be ideal. >> >>> However, >>> I can't figure out how to do this nicely because of limitations in >>> SPARQL, >>> hence the solution with boilerplate. >> >> Exactly that's the same conclusion that I also have made. Furthermore I >> remember long discussions with Arthur on the phone in November. He had >> also questioned why we cannot combine all these cases. But he also did >> not come up with a better solution. If all three of us don't come up >> with a solution then maybe there is none. > > There is no requirement that SHACL be implementable with SPARQL. We > agreed to express the formalisms in SPARQL "where appropriate" but > that is the only connection between SPARQL and SHACL. If SPARQL turns > out not to be suitable as a defining technology, then we should > abandon that resolution, or be more open about identifying the "where > not appropriate" part of the resolution. Yes. But how does your statement relate to my statement? Currently, all of SHACL Core except for the (controversial) sh:partition feature can be expressed in SPARQL + the sh:hasShape function. What I am discussing in this thread is whether the SPARQL-based SHACL extension mechanism (advanced sections) can be optimized so that as little code as necessary needs to be written by extension authors. HTH Holger
Received on Sunday, 5 June 2016 02:09:40 UTC