Implement Instances goo model

[syphax-bouazzouni]

What?

This pull request implement Instances (goo) model.

Why?

In Agroportal, we have some ontologies that have a significant number of instances (e.g E-PHY ontology with 127856 instances), those instances contains rich informations that worth been see in a UI , so we thought implementing that would be a good contribution for the ontoportal code (see issue agroportal/project-management#119) and become a good added value for ontoportal users.
However before the UI we needed first to implement pagination for the instances of a class (which wasn't done before and cause problems when we have a large number of instances), so this pull request is the result that we got.

How?

Before this PL in the InstanceLoader was hard coded a SPARQL query fro getting all the instances of an ontology or class than do a range delimitation for the pagination (only in the case of instances of an ontology) , but we thought after adding the pagination to the classes too, that it will be better if we Implement a goo model for representing "Instances" and refactored the InstanceLoader to use the goo api.

So we created a goo model for the instances and refactored all the InstanceLoader for no more using hard coded SPARQL queries but instead the goo api which make the code more clean and more harmonized with the rest.

For note: There is no more need of the class "InstanceLoader" in the this project, we can directly move it to the "ontologies_api" projects. (like done for classes or others)

Some notes and discussion about futur contributions

• We have set in the Instance model the attributes skos:prefLabel and rdfs:label as the default labels to print/use.
• We haven't implemented the portal prefLabel for instances (like the one generated for classes in the parsing using the prefLabelProperty)
• A good contribution to this, is to add the indexing of Instances like done for classes, so that we can use the search for instances too (same for properties).

Screenshots

Instances by class

Anything Else?

About me: IT engineer at LIRMM & MISTEA for Agroportal (France)
contact me at : [email protected] or in the Ontoportal Alliance Slack

[jvendetti]

Hi @syphax-bouazzouni. Thank you for the effort thus far in implementing pagination for the /instances endpoint.

If you're considering two different solutions to the same problem, we prefer that you submit them as separate pull requests. It's more straightforward for us internally to view, discuss, run unit tests against, and accept/reject a pull request when it contains a single implementation.

In general, we'd prefer to avoid commit histories on the master branch where two different implementations are committed, one of which ultimately has to be reverted.

[jonquet]

Discussed this today with @syphax-bouazzouni
@jvendetti would you like us to separate this in 2 PRs that you could choose or is this ok like that this time?

FYI: We have chosen the 2nd solution in AgroPortal which sound cleaner to @syphax-bouazzouni ... however if you guys prefer to stay on the first one which is less invasive but less harmonized with the rest of the code... let us know we can rollback here to be sure we have both the same solution.
What are you thoughts?

UIs to come will work independently of the solution chosen (cf. ontoportal-lirmm/bioportal_web_ui#16)

[jvendetti]

In the interest of saving everyone some time, I think we should just try to move forward with evaluating this single pull request. Particularly now that you've indicated that the most recent commit contains your desired solution.

Going forward, I'd prefer the approach I suggested above where any given pull request contains only your desired solution, vs. multiple solutions for us to choose from.

[syphax-bouazzouni]

Hi all,
I did an update of this PL with our latest modifications and I took the opportunity to clean up the PL description and remove the unused proposition and let only the one we deployed in production.