Re: SHACL recursion based on SPARQL (idea)

I do not intent to fight for recursion of course :)
My motivation was to rely on SPARQL and avoid the discussion on corner
cases and just accept what SPARQL returns (or not returns).
We have Ted & Eric (and Andy through TQ) on the group that can provide
details on those cases but I am happy to put this idea aside for now.


On Thu, Mar 3, 2016 at 8:54 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> I don't think that you can reply exclusively on SPARQL for this.  The
> problem
> is that the answer for ex:o1 depends on ... the answer for o1, which I
> don't
> think SPARQL alone can handle.
>
> peter
>
> On 03/03/2016 11:36 AM, Dimitris Kontokostas wrote:
> >
> > On Thu, Mar 3, 2016 at 8:17 PM, Peter F. Patel-Schneider
> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> >
> >     It looks to me as if this is a way to determine what to run the
> shapes on in a
> >     bottom-up implementation.  However, it does not appear to address
> how to
> >     determine results when recursion happens, at least as far as I can
> see, and
> >     that is the issue that needs to be addressed for SHACL in general.
> >
> >     For example, how does this approach address whether there is a
> violation in
> >
> >     ex:a rdf:type ex:Person ;
> >          p1 ex:o1 .
> >     ex:o1 p2 ex:o2 .
> >     ex:o2 p3 ex:o3 .
> >     ex:o3 p1 ex:o1 .
> >
> >
> > My idea was to rely on SPARQL on this, the same way we define the rest of
> > shacl in SPARQL. We can test what SPARQL returns on edge cases like this
> and
> > rely on that.
> >
> >
> >
> >     peter
> >
> >     On 03/02/2016 11:54 PM, Dimitris Kontokostas wrote:
> >     > I maybe surprising to the group that I make such a proposal :) but
> had a
> >     > (crazy) idea about enabling *some* recursion on shacl that is
> consistent
> >     with
> >     > the rest of the spec and is based in SPARQL.
> >     >
> >     > The basic idea is to use implicit scopes and property paths to
> achieve
> >     that goal.
> >     > (Note that I have not yet implemented this, this is just a draft
> idea and
> >     > wanted to see if you would like to explore more on this)
> >     >
> >     > Example:
> >     > ShpA (scopeClass ex:Person, property(p1, valueShape: ShpB))
> >     > ShpB ( property (p2, isIRI, (valueShape: ShpC))
> >     > ShpC ( property (p3, isIRI, (valueShape: ShpA))
> >     >
> >     > In this approach, every shape may have an explicit scope (such as
> >     scopeClass,
> >     > scopeNode, etc) as well as implicit scopes that derive from
> sh:valuShape.
> >     > to identify the implicit scope of a shape we traverse all the
> current shape
> >     > references to that shape from other shapes and give them implicit
> scopes
> >     only
> >     > if the other shapes have an explicit scope.
> >     > An example with make it easier to understand
> >     >
> >     > (note that this is without recursion and is  how RDFUnit has
> currently
> >     > implemented sh:valueShape)
> >     > ShpA has an explicit scope with scopeClass ex:Person (we do not
> take
> >     ShpC into
> >     > account here)
> >     > ShpB has no explicit scope and 1 implicit scope: [a ex:Person] / p1
> >     > ShpC has no explicit scope and 1 implicit scope: [a ex:Person] /
> p1 / p2
> >     >
> >     > note that ShpC gets an implicit scope from ShpA only as ShpB has
> no explicit
> >     > scope, if it did, we would add an extra scope
> >     > to put this in SPARQL, ShpC would have the following scope
> >     > select ?this where { [] a ex:Person ; p1/p2 ?this }
> >     >
> >     > if we want to add recursion into this what we could do is
> something like the
> >     > following
> >     > ShpA has an explicit scope with scopeClass [ a ex:Person]  and 1
> implicit
> >     > scope [a ex:Person] / (p1 / p2 / p3 )+
> >     > ShpB has no explicit scope and 1 implicit scope: [a ex:Person] /
> (p1 /
> >     p2 / p3
> >     > )* / p1
> >     > ShpC has no explicit scope and 1 implicit scope: [a ex:Person] /
> (p1 /
> >     p2 / p3
> >     > )* / p1 / p2
> >     >
> >     > As I said, this is just a draft idea for very simple recursion in
> simple
> >     shape
> >     > definitions.
> >     > I have not yet tested it or thought how this will behave in nested
> AND /
> >     OR (I
> >     > think NOT is out of the question anyway), I just wanted to share
> this
> >     and get
> >     > you feedback if it is worth exploring more
> >     >
> >     > Best
> >     > Dimitris
> >     >
> >     >
> >     > --
> >     > Dimitris Kontokostas
> >     > Department of Computer Science, University of Leipzig & DBpedia
> Association
> >     > Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> >     > http://http://aligned-project.eu <http://aligned-project.eu/>
> >     > Homepage:http://aksw.org/DimitrisKontokostas
> >     > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> >     >
> >
> >
> >
> >
> > --
> > Dimitris Kontokostas
> > Department of Computer Science, University of Leipzig & DBpedia
> Association
> > Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> > http://http://aligned-project.eu <http://aligned-project.eu/>
> > Homepage:http://aksw.org/DimitrisKontokostas
> > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> >
>
>


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