Closed jusa3 closed 11 months 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.
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
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.
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.
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?
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.
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).
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.
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).
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: 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.
#
Could the API method
ols4/api/v2/ontologies/ID/entities
be used instead of the logic ingetEntityJson()
? 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: 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?
Almost everything is done by now. A demonstration of different scenarios can be found in Storybook.
Three major parts remain:
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)
Error handling is included now by throwing an error in the useQuery()
queryFn
when response["elements"][0]
is undefined:
useQuery()
isError
then helps to render an error message inside the widget:
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"?
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:
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?
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.
No, the information does not seem to be available in ols3. Do we then still want to include it?
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).
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.
I did not find the information under linkedEntities in the JSON. Could you explain further?
I also found an info button on the ols4 relations widget not incorporated in our relations widget yet: It seems to be rendered whenever the key axioms is provided in the JSON:
Do we want to have this on our relations widget as well?
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/
@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
SemLookP Test API
@jusa3 After this we could merge the branch.
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 |
---|---|
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)
if(hasLocalDefinition == true):
the API's frontend page of the entity in the local ontologyelse if(definedBy !== undefined):
the API's frontend page of the entity in the first of the other defining ontologies else:
the raw IRI 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.
@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.
Create an entity relations widget as here:
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 ?