Design a replacement of control panel from the assembly line

[ledsoft]

As a user, I want to be able to comfortably use both TermIt and OntoGrapher. However, when using OntoGrapher, I need to select a set of vocabularies with which to work because OntoGrapher is unable to work with the whole repository. Instead of having to manually type the IRIs of vocabularies to use, I want to be able to open OntoGrapher with a selected (set of) vocabulary(-ies).

We discussed two options

1. Creating a new service for managing access to vocabularies
2. Allow opening OntoGrapher directly from TermIt

1. 'New Control Panel'

The original KODI assembly line had a service called Control Panel that could be used to manage vocabularies and "projects" which represented working copies of selected vocabularies. However, we are not going to implement projects. The question was whether the New Control Panel should be just a signpost that would direct users either to TermIt or OntoGrapher, or whether it should also support vocabulary management.

Supporting vocabulary management in the New Control Panel makes sense conceptually but should come with disabling vocabulary management in TermIt as well, so that the two tools do not duplicate the same functionality. However, to preserve the possibility of running only TermIt, it would have to be possible to enable/disable vocabulary management. We discussed the option to extract vocabulary management from TermIt into a separate module on which both TermIt and the New Control Panel could depend. When running with the New Control Panel, this module would be disabled in TermIt.

However, extracting this module may prove quite challenging.

2. Extend TermIt

Basically, we are interested in allowing the user to open in OntoGrapher a set of vocabularies, which they can already see in TermIt. It thus makes sense to just extend the capabilities of TermIt to open a vocabulary and its 'related' (to be defined) vocabularies in OntoGrapher. Such a change would not require that much effort.

The only downside is that we are making TermIt into an even bigger monolith.

Conclusion

After an extensive discussion we decided to go with option two. It does not prevent us from implementing option one in the future, should there be need to. Our primary goal is to develop and extend TermIt, not build a new version of the assembly line. Option two is better aligned with this goal, as well as requiring significantly less effort (given limited resources we currently have).

[ledsoft]

FYI @MichalMed @lukaskabc @blcham Feel free to comment with anything I might have forgotten.

[ledsoft]

Agreed on option 2. Created a follow-up ticket - #528.