JSON config file for mines to add extra filters

[AdrianBZG]

JSON config having the name of each mine, its service API and the filters its able to handle.

[yochannah]

will this approach still allow new mines added to the registry to be viewed automatically in the tool?

[AdrianBZG]

@yochannah Not really, since you need to hardcode each mine in that JSON file, and say which of the filters currently available in the browser its able to handle (by looking manually on the ontology concepts of that mine)... is this bad?

[yochannah]

We'd like to have it respond to new mines in the registry as the registry gets updated - otherwise there's a bit too much risk of this tool getting out of date.

A config file containing the URL of the mine is fine, so long as:

• we have defaults for mines that don't have configs and/or
• we access the still-to-be-made API endpoint that provides these configs.

Does that sound ok?

Also, once you've defined roughly what the config json should be like let me know and I'll make the ticket on InterMine to turn it into an API endpoint.

[AdrianBZG]

@yochannah What about this?:

1) JSON config file defining mines and available filters, for those mines that can handle more filters than the 4 general default ones, so that filters are added to the sidebar dinamically. 2) Fetch all mines from the registry, and for those mines that are not defined in the JSON file, only show the default 4 filters.

This way we have the possibility to work with all the new mines in the registry, and for those ones that some extra filters are working due to the ontology, we can define them so the filters are available.

How this sounds to you?

I'll tell you later what kind of constraints, in terms of concepts existing in the ontology, a mine should pass in order to handle each of the filters, so that the API endpoint can return that.

[yochannah]

ok yes, that sounds like a good approach!

[AdrianBZG]

@yochannah @rachellyne Done! 🥇

http://im-browser-prototype.herokuapp.com/