Re: N3 loops , validation and cutoffs

Hi Patrick,

On Sun, Nov 14, 2021 at 12:38 PM Patrick Hochstenbach <
Patrick.Hochstenbach@ugent.be> wrote:

> Hi
>
>
> I'm learning about N3 for a PhD project on decentralized scholarly
> communication I joined this year (at IDLab in Ghent). In this project we
> want to use N3 as rule books published online that get executed by
> browsers, intelligent agents, servers to start some business logic.
>
>
> Great!

> There are some things in N3 where I need a bit more insight. One is the
> processing of N3 requires some kind of recursion (due to the fact that
> formulas can be in any order, the result of a formula can be the input of
> the same formula). These recursions can lead to infinite loops as in this
> (pathetic) example:
>
>
> @prefix : <urn:x:>.
>
> :Hank :loves :Pizza.
>
> { ?X :loves ?Y . } => { [] :loves ?X . } .
>
>  I know that in EYE (and probably also in CWM) these loops can be
> prevented by introducing a cutoff in the reasoning engine (asking the
> engine to stop processing formulas at some point).
>
Well, in your above example EYE will not loop because it tries to produce
lean graphs (see https://www.w3.org/TR/rdf11-mt/)
and it stops when no more new triples can be produced.

>
> Is it possible add extra formulas that can prevent that these cutoffs are
> needed? I know I'm asking for a solution to the halting problem, but just
> to be sure I don't miss anything obvious. When receiving N3 documents from
> third parties, my engine don't know what cutoffs or optimizations are
> required.
>
Could you give a different example where "cutoffs" should be needed?

> I am also curious why CWM and EYE give different answers for this
> (pathetic) example:
>
>
> @prefix : <urn:x:>.
>
> :Hank :loves :Pizza.
>
> { ?X :loves ?Y . } => { [] :loves ?Y . } .
>
> CWM:
>
> [      <urn:x:loves> <urn:x:Pizza> ].
>
>
> EYE:
>
>
> {no new quads produced}
>
>
> Indeed and the reason is that EYE tries to produce lean graphs (see
https://www.w3.org/TR/rdf11-mt/)

Kind regards,
Jos

> BR
>
> Patrick
>