Form choice field can't find implicit members of a class when subclasses are defined in a separate ontology document

[josephguillaume]

Unfortunately this was introduced by #511 because looking for classes in other documents was considered a bug linkeddata/rdflib.js#565

The problem is that it seems to mean that data needs to be defined in the same file as its ontology.

E.g.
If I have an ontology document that specifies

:FeatureClass1 rdfs:subClassOf sosa:FeatureOfInterest.
:FeatureClass2 rdfs:subClassOf sosa:FeatureOfInterest.

and in a separate form document I have

:form a ui:Choice;
ui:from sosa:FeatureOfInterest

And then my data document has

:Feature1 a :FeatureClass1.

Then even if all documents are loaded in rdflib, I get the error "Can't do selector with no options" because :Feature1 is not recognised as an implicit instance of sosa:FeatureOfInterest.

One work around is to repeat rdfs:subClassOf definitions in the data doc, which is not ideal.
A second is to explicitly define each instance with both the subclass and superclass. Also not great.

:Feature1 a :FeatureClass1, sosa:FeatureOfInterest

Given that this came about because results were being returned from too many documents, the solution is probably to be more explicit about which documents should be taken into account when using findMembersNT to discover members of subclasses.

A starting point would be following ones nose by dereferencing :FeatureClass1 and :FeatureClass2 and taking into account the ontology doc in which they are defined. But if there are many classes, then the list of ontology documents to take into account might grow fairly quickly, and not every class used in the data doc might be relevant...?

Edit:
Turns out my situation is actually even worse, because the form is for sosa:Observation, so the data docs are collections of observations which all point to a separate document defining the instances of sosa:FeatureOfInterest.
The necessary workaround is therefore to redefine every instance of sosa:FeatureOfInterest in every observation document.

Rather than guessing what should be dereferenced, probably the easiest solution then is to use rdfs:seeAlso and have findMembersNT use definitions within them.
In terms of implementation, I think this would involve creating a new rdf store with only the desired documents and calling findMembersNT on that. I don't know what the performance implications would be, but it seems like a store that could be reused in other places in the form library??

[bourgeoa]

Unfortunately this was introduced by #511 because looking for classes in other documents was considered a bug linkeddata/rdflib.js#565

Isn't @timbl proposal the solution ?
linkeddata/rdflib.js#565 (comment)

[josephguillaume]

Isn't @timbl proposal the solution ?

No, @timea-solid did already implement a version of findMembersNT that takes as argument the document to search.

solid-ui/src/widgets/forms.js

Line 2220 in 5b3471f

function findMembersNT (store, thisClass, quad) {

Unfortunately that's too restrictive - we need to be able perform inference across multiple documents (my suggestion is the dataDoc+seeAlso).
Timea will be better placed to judge, but I think specifying a list of documents complicates things, which is why my suggestion was that we construct a new RDF store that only contains the required documents.

[bourgeoa]

If the argument parameter is null then the search should be over the whole store.