FZJ-INM1-BDA / siibra-python

Software interfaces for interacting with brain atlases - Python client
Apache License 2.0
46 stars 8 forks source link

Removal of EBRAINS access token #555

Closed romina1601 closed 5 months ago

romina1601 commented 5 months ago

This isn't necessarily an issue, but more of a question to better understand siibra and the access to the KG. I am working on integrating v1.0a5 of siibra into TVB and I noticed that, starting with v0.4a78 you removed the documentation regarding the EBRAINS access token. Indeed, when using siibra to retrieve structural and functional connectivities from the KG, I noticed that the token is not necessary anymore. So, my question is, why is that? What changed about the access to the KG? Do you expect that the EBRAINS token will be required again to access KG data anytime in the future?

xgui3783 commented 5 months ago

Speaking from someone who is (now) more tangentially related to siibra-python development, I can shed some light on the issue.

When

Starting from 0.4a63 or more specifically 002b53ac99e7f6c23f29aa9cfec7dca313c78880 , ebrains query of publicly available data no longer required an ebrains token. The documentation was removed a little later, as you noted.

Why

Requiring an ebrains token to be able to access publicly available information had been a tremendous friction point, not only for us (e.g. during demo, we needed to add an extra step, which adds possibility of failure, breaks the flow of demo), as well as to users, who may not have ebrains account, or developer privilege to query KG.

It has been made clear to us that KG will not make an anonymous endpoint. We were also informed that, the correct way to use KG, is to use a caching layer ourselves, so that the query does not hit KG directly, but the cache. This (IIRC) is also how KG search UI show its data to its users without authentication.

How

We took a snapshot of the entire query, and put the snapshot on a bucket bucket on data-proxy. When user of siibra-python queries the metadata of a specific feature/atlas concept, it often (but not always) have a dataset id/dataset version id. We fetch the corresponding JSON file from the public public.

In hindsight, it might be more suitable for us to favor doi content negotiation, and only use cached dataset version etc as a fallback.

About the future

As far as public data is concerned, I do not expect ebrains token will be needed in the future. (not a promise)

romina1601 commented 5 months ago

Thank you, @xgui3783 , for all the clarifications! 👌🏻 You definitely made things clearer (for me).