Re: Thoughts about log:collectAllIn

Dear Doerthe,

Good point and we could say that the log:collectAllIn answer is a multiset
and
introduce a log:multisetEqualTo and log:multisetNotEqualTo which I tried in
https://github.com/josd/eye/releases/tag/v22.1126.0121

Jos

-- https://josd.github.io


On Fri, Nov 25, 2022 at 5:39 PM Doerthe Arndt <doerthe.arndt@tu-dresden.de>
wrote:

> Correction: I think the output should not be a set but a multiset, but the
> we would also need to define.
>
> Kind regards,
> Dörthe
>
> Am 25.11.2022 um 17:33 schrieb Doerthe Arndt <doerthe.arndt@tu-dresden.de
> >:
>
> Dear all,
>
> Motvated by our latest discussion on built-ins and their specification, I
> further thought about the nature of log:collectAllIn. It is very
> interesting that in EYE  the output of the built-in depends on the order
> the reasoner reads in the triples. As an example compare the following two
> examples in the editor:
> ABC: http://ppr.cs.dal.ca:3002/n3/editor/s/eTcoBQb2
> ACB: http://ppr.cs.dal.ca:3002/n3/editor/s/w2LhPbCZ
>
> By this parsing-order dependency we might also get some implementation
> dependency and I think that we should avoid that. One solution for the
> problem would be to simply make log:collectAllIn non-deterministic, but I
> think that this would break many of our applications. So, an alternative
> idea would be to fix the order in some other way which we than also
> communicate (for example string-order of the full uri or literal).  But If
> we do so, we should specify that clearly. As we already have a set
> predicate, we could say that we give the output as a set.
>
> The problem with that solution is, that it is quite handy that in the
> current implementation the reasoner keeps for example the order of a list
> if used as input. Consider for example the following:
> http://ppr.cs.dal.ca:3002/n3/editor/s/GfsbVdjC
>
> So, should we introduce an extra predicate for use cases like the last one?
>
> How would you define the built-in in order to guarantee interoperability?
>
> Kind regards,
> Dörthe
>
>
>