ts4nfdi / terminology-service-suite

The Terminology Service Suite project is a collection of interactive widgets designed to ease the integration of terminology service functions into third-party applications.
https://ts4nfdi.github.io/terminology-service-suite/comp/latest/
MIT License
16 stars 2 forks source link

entity relations widget #29

Closed jusa3 closed 11 months ago

jusa3 commented 1 year ago

Create an entity relations widget as here: image

You can either

I'm not sure what informations exist (subclass of, related from ...) - maybe you can have a look at some entities. Do you have a complete list @rombaum ?

VincentKneip commented 1 year ago

There are many types of information such as:

A complete list of all entityPageSections can be found by looking into this directory of the OLS4 repository. Every file implements one section.

jusa3 commented 1 year ago

Then starting with the ols4 component/code might be a better option. And if we use the ols4 code, wouldn't it be nice to incorporate the widget into the ols4 code as Julian did with the entity tree widget? @julian-schneider

julian-schneider commented 1 year ago

If we wanted to use their element 1:1 in SemLookP, we could widgetize their code and plop it into this project. But the styles wouldn't match, sadly. I think this is a smaller issue for the EntityTreeWidget than it would be for the relations widget.

VincentKneip commented 1 year ago

Yes, I will start with looking at the ols4 code. By the way, the code for the Relations widget in ols4 can be found here.

VincentKneip commented 1 year ago

Some information displayed in the relations widget is contained directly in the entity's JSON, like parents for subtypes or types for individual type (example). Unfortunately though, this is not always the case, like for different from for individuals (example). Therefore, fetching the data from the JSON won't be an option.

In ols4, the information lies in a properties attribute (type any, so I don't really know what this is) of the class Thing and its subclasses Entity, Class, Individual etc. (located in the same folder), which is treated like some kind of array. For example, to retrieve the types of an individual, this function is used.

The entities are accessed via an ontologies slice which is incorporated in a React redux store reducer via the useSelector hook.

Implementing all of this in semlookp-widgets seems a bit too much for a single widget. Can some else maybe have a look on how we can extract the sections information with a simpler and more suitable method for semlookp-widgets?

julian-schneider commented 1 year ago

We found out that the v2 API appears to contain all of the types displayed in the OLS4 frontend (example), so it can be extracted from the JSON.

VincentKneip commented 1 year ago

Pushed a first version, subclass of and different from are implemented, but not styled properly yet. Manchester syntax, hyperlinks, ... are not yet included.

We should probably think about how to organize the code well because it will be a lot in the end. Maybe create a function for every section. Maybe it would be better to let useQuery save the whole response object so that only one function for every section is needed (extracting the relevant information for the section from the response and returning the corresponding JSX element).

jusa3 commented 1 year ago

Looks good so far. I would prefer letting useQuery save the response, because it's less time consuming querying once compared to querying for every section.

If it becomes unclear/too much code you can think about creating sub-components. The widget does not have to consist of only one component.

btw there is a new endpoint in the ols4 API, that is not yet in the documentation but will be with the release. https://www.ebi.ac.uk/ols4/api/v2/ontologies/ncit/entities?iri=http:%2F%2Fpurl.obolibrary.org%2Fobo%2FNCIT_C2984 or https://www.ebi.ac.uk/ols4/api/v2/entities?iri=http:%2F%2Fpurl.obolibrary.org%2Fobo%2FNCIT_C2984 with the key "entites" instead class/term/property/individual. I didn't look into the information you get yet but maybe this may help a bit with optimization of the code.

VincentKneip commented 1 year ago

Done! useQuery now just saves the response. The sections are realized as pseudo sub-components at the moment (extracting the information in a function which then returns the JSX element for the section).

I did not look into the new endpoint yet, however my goal so far is to do as few api calls as possible. For now, only one call (the one for the respective entity) suffices.

Hyperlinks and labels are now available for subclass of and different from. The links for now lead to the respective iri url, but should probably lead to the respective semlookp pages later.

A first experiment with the Manhattan syntax is now pushed (see here). However, not everything is covered yet (e.g. only keyword, for which I did not find an example entity yet).

julian-schneider commented 1 year ago

Could the API method ols4/api/v2/ontologies/ID/entities be used instead of the logic in getEntityJson()? That should not require more requests.

And yeah, it would be handy if the hyperlinks lead to semlookp pages. But what if the entity is not hosted on semlookp at all, that can happen right? Either the links point to different locations, depending on whether their target is hosted by semlookp, which might be confusing. Or there are multiple clickables - How about something like this: image Where the label hyperlink always points to the IRI, and if the entity exists in semlookp, the extra bubble is added and points to the semlookp entity page.

VincentKneip commented 1 year ago

#

Could the API method ols4/api/v2/ontologies/ID/entities be used instead of the logic in getEntityJson()? That should not require more requests.

And yeah, it would be handy if the hyperlinks lead to semlookp pages. But what if the entity is not hosted on semlookp at all, that can happen right? Either the links point to different locations, depending on whether their target is hosted by semlookp, which might be confusing. Or there are multiple clickables - How about something like this: image Where the label hyperlink always points to the IRI, and if the entity exists in semlookp, the extra bubble is added and points to the semlookp entity page.

ols4/api/v2/ontologies/ID/entities is now used instead of the logic in getEntityJson().

Regarding the hyperlinks The label hyperlink in EBI OLS references the EBI OLS page of the specific entity inside the ontology of the currently viewed entity. The badges reference the EBI OLS page of the specific entity inside its defining ontology. If the defining ontology is the same as the ontology of the currently viewed entity, no badge is shown, if the entity is defined in multiple ontologies, multiple badges can be shown.

Since the ontologies of SemLookP will be limited, it would probably be better to make the label reference the iri-URL because the SemLookP-page might not exist. If pages exist, differently colored Badges for currently viewed and defining ontologies could be shown.

What do think of this idea @rombaum ? How do you imagine the look and functionality of the widget?

VincentKneip commented 1 year ago

Almost everything is done by now. A demonstration of different scenarios can be found in Storybook. grafik

Three major parts remain:

  1. How should the widgets' appearance be?
  2. Where should the hyperlinks redirect to/ what badges do we want? (see comment above)
  3. What does onDataType do in Manchester syntax?
jusa3 commented 1 year ago

Well done!

The widgets appearance: since the new SemLookP app does not have any style yet, I would keep this widget as simple as it is for now. Questions 2. and 3. @rombaum

Please add error handling if the API request can't be resolved (e.g if the terminology is not available) - at least an error event. Maybe also some information for the user of the website e.g. "Terminology not available" or sth. else. See https://www.ebi.ac.uk/ols4/api/v2/ontologies/mesh/entities?iri=http:%2F%2Fpurl.bioontology.org%2Fontology%2FMESH%2FD004194 (IRI: http://purl.bioontology.org/ontology/MESH/D004194)

VincentKneip commented 1 year ago

Error handling is included now by throwing an error in the useQuery() queryFn when response["elements"][0] is undefined: grafik

useQuery() isError then helps to render an error message inside the widget: grafik

jusa3 commented 1 year ago

There are other reasons for the entity not beeing resolved, too (e.g. wrong entity type). The error message inside the widget should be more general. How about "Requested resource not available"?

VincentKneip commented 1 year ago

Wrong entity types don't make a difference anymore since the widget is now using the universal ols4/api/v2/ontologies/ID/entities route. But the api server being down would be another reason, so you're right. The error message is now changed:

grafik

VincentKneip commented 1 year ago

Regarding onDataType: The label "http://www.w3.org/2002/07/owl#onDatatype" only seems to occur within "http://www.w3.org/2000/01/rdf-schema#range" used in the RangeSection, defining value restrictions (example). However, RangeSection is only part of the Information, not the Relations section which the widget represents.

But with this comes the question: Should the EntityInfoWidget of SemLookP be modified to show all the info displayed on the Information section of OLS?

jusa3 commented 1 year ago

All widgets (except relations widget and hierarchy widget) must work with the ols3 API. If this info can be retrieved from the ols3 API then yes. The implementation gets a bit more complex if it's only available in the ols4 API. We would need a condition based on the use of the API version and documentation.

I opened two more issues #30 and #31 that can be prioritized.

VincentKneip commented 1 year ago

No, the information does not seem to be available in ols3. Do we then still want to include it?

jusa3 commented 1 year ago

Hm then maybe let's first do the metadata widget refactoring to get a feeling on how complex the switch between ols3 and ols4 will be (because we have the requirement of users for the metadata widget to get it to work with the IRI only -> needs ols4).

rombaum commented 1 year ago

First of all. @VincentKneip Nice Work!

2. Where should the hyperlinks redirect to/ what badges do we want? (see comment [above](https://github.com/nfdi4health/semlookp-widgets/issues/29#issuecomment-1723833773))

To answer this question I will use your example from the storybook. From my perspective if the entity is in SemLookP it should be used as target of the link. This is defined under the key linkedEntities in the JSON. The badge should be a optional parameter in the widget. By default it should be hidden. The parameter could named "show_badge". The data of the badge will only appear if the other ontology is loaded to ZB MED. If this is not the case we should use the purl as the target link.

VincentKneip commented 1 year ago

I did not find the information under linkedEntities in the JSON. Could you explain further?

VincentKneip commented 1 year ago

I also found an info button on the ols4 relations widget not incorporated in our relations widget yet: grafik It seems to be rendered whenever the key axioms is provided in the JSON: grafik

Do we want to have this on our relations widget as well?

jusa3 commented 11 months ago

What is the status? Can we merge? @VincentKneip @rombaum

As a last step please test the widget with following API: http://ols4.qa.km.k8s.zbmed.de/ols4/api/v2/ @VincentKneip

Have a look into the available ontologies: http://ols4.qa.km.k8s.zbmed.de/ols4/api/v2/ontologies/

rombaum commented 11 months ago

@VincentKneip

I found an example where a class relation entity could be linked local and/or external depending of the API. The ontology MONDO is loaded to the OLS4 instance from EMBL-EBI. In our test enviroment MONDO is not loaded. In both OLS4 instances the ontology EFO is loaded.

You could use diabetes mellitus (EFO:0000400) from EFO as an example. By looking to the API [1] and [2] you could see how the entity endocrine pancreas disorder (MONDO:0001933) is linked to diabetes mellitus (EFO:0000400). For the OLS4 instance of EMBL-EBI it is defined by "mondo". In our test instance the property defined by is missing.

OLS4 API

grafik [1] https://www.ebi.ac.uk/ols4/api/v2/ontologies/efo/classes/http%253A%252F%252Fwww.ebi.ac.uk%252Fefo%252FEFO_0000400/

SemLookP Test API

grafik [2] http://ols4.qa.km.k8s.zbmed.de/ols4/api/v2/ontologies/efo/classes/http%253A%252F%252Fwww.ebi.ac.uk%252Fefo%252FEFO_0000400/

@jusa3 After this we could merge the branch.

VincentKneip commented 11 months ago

Implemented the suggestions of @rombaum. Badges can now be turned on and off using the property showBadges: boolean (provided $\Leftrightarrow$ badges are shown) and look like this:

Our EntityRelationsWidget for UBERON_0000006 EMBL-EBI ols4 Relations Section for UBERON_0000006
grafik grafik

Badges are shown for definitions of an entity within ontologies other than the local ontology (the one you're currently in) and link to the API's frontend page of the entity in the respective ontology.

The label of the entity links to (see here for more information)

VincentKneip commented 11 months ago

To be convenient with the other SemLookP widgets, the EntityRelationsWidget also gets passed the api without v2 (e.g. http://ols4.qa.km.k8s.zbmed.de/ols4/api/ instead of http://ols4.qa.km.k8s.zbmed.de/ols4/api/v2/) now and adds v2 internally afterwards.

VincentKneip commented 11 months ago
@jusa3 After this we could merge the branch.

Some TODOs (e.g. disambiguation page) still remain, but the requirements of @rombaum should now be fulfilled. The branch should therefore be able to be merged for now.