You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started by introducing an Enum class for UniProt fields (2c6f5b9) which can be used to dynamically set the fields to download and pass to BioCypher in the crossbar build script. Not sure, however, if Enums are the best way from a user-friendliness perspective. The aim is to abstract the process of using any given adapter as someone who wants to build a database, particularly in the case when the user does not know about specifics of the API of the primary source. Enums offer autocomplete, so at least the "knowing about adapter contents" is facilitated a bit.
We can think about it and discuss alternatives.
The text was updated successfully, but these errors were encountered:
As another option, maybe we can use some type of configuration file where users can choose which fields to download. I think this option has 2 advantages. First, since Uniprot has lots of fields to download (https://www.uniprot.org/help/return_fields), this can prevent fields from being crowded in the adapter script. Second one is, for non-specialist users, this method seems more user friendly option.
For example, configuration file might be something like this:
xref fields:
entrez: true
kegg: false
...
However, this feels like we are taking away that feeling of programming for other type of users.
i think having both options is a good solution, then users can decide what to do. enums have the advantage of auto-complete (as you are typing, you see which fields are provided by the resource and how it is spelled), which prevents user input failures.
I started by introducing an Enum class for UniProt fields (2c6f5b9) which can be used to dynamically set the fields to download and pass to BioCypher in the crossbar build script. Not sure, however, if Enums are the best way from a user-friendliness perspective. The aim is to abstract the process of using any given adapter as someone who wants to build a database, particularly in the case when the user does not know about specifics of the API of the primary source. Enums offer autocomplete, so at least the "knowing about adapter contents" is facilitated a bit.
We can think about it and discuss alternatives.
The text was updated successfully, but these errors were encountered: