- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sun, 5 Jun 2016 17:10:50 +1000
- To: kcoyle@kcoyle.net
- Cc: public-data-shapes-wg@w3.org
Peter, could you clarify whether you were only talking about the core constraint components and how the spec would define them, or about the general mechanism? I am not too concerned about how we write things in the spec. There is only one SPARQL query per component right now in the spec. Thanks Holger Sent from my iPad > On 5 Jun 2016, at 3:39 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > > > >> On 6/4/16 7:09 PM, Holger Knublauch wrote: >> >> >>> 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. > > The subject on this mail is "implementing (core) constraint components universally." Peter's mail, if I am not mistaken, addresses only core constraints, and a desire to "universalize" those core constraints. His example here was minCount. I don't see where this has to do with the extension mechanism. If what is described today in SHACL core can be implemented in SPARQL, that doesn't mean that we can't discuss an implementation that doesn't use SPARQL if we think that would be better. There is no reason why the core must be implemented in SPARQL, and for sure we should not allow SPARQL limitations decide the direction of SHACL. > > kc > > >> >> HTH >> Holger >> >> >> > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 >
Received on Sunday, 5 June 2016 07:11:23 UTC