Re: Thoughts about log:collectAllIn

My main use-cases for log:collectAllIn are for cardinality checks (how often does a triple pattern occur in a context.

I think in RDF context I am already used to the fact that no order can be assumed unless an explicit list is provided in the data. It depends not only on indexation but also on the serialisation of the input data.

Two n3 reasoners shouldn't assume that any two input RDF documents are different just based on the ordering of triples.

The same discussion is also relevant for the graph:list , I assume?

Patrick
________________________________
From: William Van Woensel <william.vanwoensel@gmail.com>
Sent: 26 November 2022 14:43
To: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
Cc: public-n3-dev@w3.org <public-n3-dev@w3.org>
Subject: Re: Thoughts about log:collectAllIn

Hi Doerthe, everyone,

With non-deterministic, do you mean the Prolog definition<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.swi-prolog.org%2Fpldoc%2Fman%3Fsection%3Ddeterminism&data=05%7C01%7CPatrick.Hochstenbach%40ugent.be%7C8d2076c1e02c412243a008dacfb44136%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638050670342727729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kn0qo7zCiD0mdJIl1l0vCIoR7Sf1QFY8a5Kt%2FOjpRq0%3D&reserved=0> or the case where an algorithm may return different results for the same input?

Speaking for myself, none of my use cases rely on a pre-defined order of results. (Since, for jen3, this would not only depend on parsing order, but also how triples are indexed.) From that viewpoint, I’d rather propose defining the builtin as not imposing any particular result ordering. Or, more accurately, the same ordering is guaranteed as with rule triple patterns in general: e.g., in case of basic graph patterns, no ordering is expected, but for builtin statements (such as your list:in example), the list order would be followed.

Do you (or Jos, or others) know any current use cases that rely on a parsing (or other) order dependency?


Regards,

William

On Nov 25, 2022, at 11:33 AM, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:

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