Thoughts about log:collectAllIn

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