Schemes filter issues

[martinaPulieri]

The concepts are not filtered in the proper way by the "Schemes" filter. "Body shape" doesn't belong to the "PhytoplanktonTraits" scheme.

[jonquet]

Well, this situation may in theory occur and was discussed when we implemented support for schemes.
In fact, Schemes are browsed by hierarchies. So you start with a top level concept that IS in the scheme and you can start browsing the narrower concepts. Then, if a narrower concept is not in the scheme AND is a leaf then we shall not display it. But if the narrower concept is not in the scheme BUT has itself other narrower concepts then we took the decision to display it in order to get access to the narrower concepts of the narrower concept that could themselves be in the scheme.

Could you confirm this is what's happening here?
What would be an alternative behavior according to you?

[martinaPulieri]

The behaviour that you are describing is 100% correct, but I know that in this thesaurus, inside this "body shape" concept there isn't any other skos:concept associated to the "PhytoplanktonTraits" scheme. I double checked it also in VocBench to be sure.

[jonquet]

Do you mean: Nor this "body shape" concept nor any of its descendants are in the "PhytoplanktonTraits" scheme?
If yes, then indeed, it should not display then.

[martinaPulieri]

Yes, exactly

[syphax-bouazzouni]

Fixed in ontoportal-lirmm/ontologies_linked_data#166,
@martinaPulieri you can check it again in https://ecoportal.lifewatchdev.eu/ontologies/TRAITSTEST?p=classes&concept_schemes=https%3A%2F%2Fkos.lifewatch.eu%2Fthesauri%2Ffunctraits%2FconceptScheme_45c75a99&conceptid=https%3A%2F%2Fkos.lifewatch.eu%2Fthesauri%2Ffunctraits%2Fc_621df9ab

[martinaPulieri]

It's a start, but I am not sure about this solution. In VocBench, when we select a schema, all the skos:concept that do not belong to that schema are not shown. This way is more user friendly.

[syphax-bouazzouni]

It's a start, but I am not sure about this solution. In VocBench, when we select a schema, all the skos:concept that do not belong to that schema are not shown. This way is more user-friendly.

@martinaPulieri it is the case, we don't show the concepts that are not in the scheme,
except if the concept has children, as we don't know in advance if they have or not children from the scheme.
You can see here the before and after ontoportal-lirmm/ontologies_api#104

[martinaPulieri]

It is best if the concepts that do not belong to the concept scheme selected are not shown.

[jonquet]

Hi Martina, I got your point too.
However, we have to find a response to the situation where a skos:ConceptScheme is not a connected graph (https://en.wikipedia.org/wiki/Connectivity_(graph_theory)#Connected_vertices_and_graphs).
I mean the SKOS specification does not status on this: This is ok in SKOS to have a Concept Scheme graph in multiple disconnected part. In that case, the only way for us is to traverse thru concepts that are not in the scheme to connect again with new concepts that could be in the scheme later (when opening the hiearchy down).

To be honnest, I don't think VocBench "manage" this situation... but as an editor it would mean that it does not support or facilitate the fact of creating such disconnected schemes. Still on our side, we could get SKOS resources that will have this.

I am CC @saubin who is also familiar with SKOS for her opinion.

[jonquet]

Rediscussed in technical meeting today afternoon. Lets wait for @martinaPulieri and @saubin feedback on this.
Technically is easy/possible to do (do not display them) but it "hiding the problem" until someone deposit a SKOS vocabulary that will have the "disconnected graph" situation.

[martinaPulieri]

In addition to the proposed solution, we can consider adding a check box that says "Hide concept". It can be an intermediate solution

[jonquet]

We have a plan for multiple enhancement and parameter for the tree view (@syphax-bouazzouni might put the issue in)
We can indeed have a check box in this future "tree view config" panel to "Display the concepts not in the scheme (but with possible descendants in the scheme" => by default it would not be activated (so you will get the expected behaviour, that will probably be the most frequent) and with this activated the other concepts susceptible to have descendants in the scheme will be explicitly added.

I like this approach.

[martinaPulieri]

If it can be implemented, I think it's a good solution.

[syphax-bouazzouni]

We have a plan for multiple enhancement and parameter for the tree view (@syphax-bouazzouni might put the issue in) We can indeed have a check box in this future "tree view config" panel to "Display the concepts not in the scheme (but with possible descendants in the scheme" => by default it would not be activated (so you will get the expected behaviour, that will probably be the most frequent) and with this activated the other concepts susceptible to have descendants in the scheme will be explicitly added.

I like this approach.

If it can be implemented, I think it's a good solution.

@jonquet , @martinaPulieri , that is more like a long-term solution (2-3 weeks work to implement, with the UI and API changes, and testing), here we need to take a short-term decision (1-2 days to implement and test), two options:

• Option 1: we don't change the default behavior that is currently implemented, and wait in the future for a better version of the Tree.

• Option 2: We hide the concepts by default and accept that we do not support the edge case Clement described, until a better version of the Tree in the future.

[martinaPulieri]

We have to face the fact that most of the SKOS vocabulary do not have multiple concept schemes. If you browse among the ones published in the OntoPortal instances, you will notice that (only execption is AGROVOC probably).

I know that in EcoPortal we are going to publish a couple of SKOS thesauri with multiple concept schemes and we need not have the user view crowded with multiple concepts that do not belong with the same scheme.

Therefore, i will go with option 2 for the moment.

[syphax-bouazzouni]

OK, I will implement that, today or tomorrow, and I will ping you once done.

[jonquet]

Fine with me for now too. Still interested in @saubin 's opinion for the record and the long term.
Also, be sure capture the feature request in another issue for future dévelopment.
Cool we converge and this is useful!

[syphax-bouazzouni]

OK, I will implement that, today or tomorrow, and I will ping you once done.

@martinaPulieri I deployed the change in https://ecoportal.lifewatchdev.eu. Can you try again and tell me if everything works as you expected,

[martinaPulieri]

@syphax-bouazzouni it works perfectly. Thank you