findMembersNT searches the whole store not just one document

[timea-solid]

I found a bug in my demo. And I nailed it down to a function in rdflib that does not take care to query in a given quad (context/graph):

rdflib.js/src/formula.ts

Line 400 in c14dfd5

ref1 = this.statementsMatching(void 0,

-> mind the missing quad
Example propagation of code:

Now, one can debate this is a feature... I believe this to be a bug.
My store has loaded 2 similar resources but I specifically (well the solid-ui forms code) queries for data from only ONE resource and still, because of the findMembersNT function in rdflib retrieves cross resource all possibilities -> hence I got DUPLICATE records (triples) because they are different only in the quad they are stored on.
This bug is nasty, unless you know RDF really well you could not deduce this. (lucky I came across such behavior before)

[timbl]

The mashlib was originally developed for mashing up (combining together usefully) all sorts of data from different trusted sources. So if you have loaded data from Wikidata which says 5 things are cities, and some from DBPedia that says 7 things which are cities, then you want to find all 12. That's why it is like it is.

In your case the fact that you have duplicates is the thing you notice, and certainly the function may be more useful if it removed duplicates.

But the main thing which surprised you seems to be that the function searches the whole store, instead of just one document. We can certainly change the function to take an optional document to search. It i more secure, espcially now i a solid world where we see much untrusted data as well as trusted data, to be specific about which document to search .

[josephguillaume]

I've ended up here (rather belatedly) because I have a ui:Choice form that no longer works (error "Can't do selector with no options") since a customised dataDoc-specific version of findMembersNT was adopted .

This appears to be because the subClassOf definitions are in a separate file to the form, i.e. searching beyond the dataDoc is necessary, otherwise I have to duplicate those definitions from the ontology to the dataDoc.

I'll try to post something to solid-ui too, but I'd say please don't eliminate the ability to search the whole store :-)

[timea-solid]

So maybe we just need 2 functions. @josephguillaume did you end up fixing your code?

[josephguillaume]

No, I'm just using an outdated mashlib for the time being.

Based on the conversation at #535, it actually sounds like what you implemented in solid-ui was a version of this function that takes an optional document to search - and leaving the document as null maintains the current behaviour. Any reason it wasn't merged here?

[timea-solid]

Ok, so an idea is to roll this back and maybe add a new one. We shall discuss in our SolidOS meetings (next wednesday). Sorry for the breaking changes.