Re: ISSUE-139: implementing (core) constraint components universally

I was planning to ask for clarifications on this as well

Is this thread about enabling all contexts in all SHACL Core components
only or a suggestion to change the SPARQL extension mechanism in general?
These two can be independent of each other imho.

Best,
Dimitris

On Sun, Jun 5, 2016 at 10:10 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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
> >
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT