Connect our codes to OntoPortal

[syphax-bouazzouni]

Context

Starting from 2023, the centralized code for the ontoportal technologies would no more be in the NCBO organization but instead in the new ontoportal organization

Goals

Make the ontoportal organization, the entry point for anyone that wants to take, and use our technologies. And make it the centralized place for our all generic issues/projects

What do we need to do

1. Currently none of our local instances (Agroportal, ...) code is a fork of the repositories in the Organization., so I think our first goal would be in our local organization to fork the Ontoportal code. See below the current state and the target one (inspired by @graybeal 2020 kickoff presentation)
2. Merge your local code with the Ontoportal one (which means mostly for now been updated with NCBO code)
3. Migrate all your common (generic) issues to Ontoportal-specific project

Why we need to do it

For multiple reasons, among them

• It is essential for making pull requests and collaborating (it is impossible to do pull requests if you are not a fork of a project)
• Will make things easier after to get your local code updated/centralized with the upstream one using GitHub actions
• Centralized issues/pull requests will make people know what you are working on and may even give help (or do it for you)

Follow-up

• [x] BioPortal
• [x] AgroPortal https://github.com/agroportal/project-management/issues/312 (planned to be done in January-February 2023)
• [x] SIFR BioPortal (done as AgroPortal)
• [x] IndustryPortal (see https://github.com/IndustryPortal)
• [x] BiodivPortal (see https://github.com/BiodivPortal)
• [ ] MatPortal
• [x] EcoPortal (see https://github.com/lifewatch-eric)
• [ ] MedPortal
• [x] EarthPortal (see https://github.com/EarthPortal)
• [x] TechnoPortal (see https://github.com/EarthPortal)
• [ ] AstroPortal see https://technoportal.hevs.ch/)
• [ ] LovPortal

[syphax-bouazzouni]

I hope that i was clear, it is only a proposition (open for discussion).

For the how do you achieve is ? It is let for your local team to decide of the how and the when. For the case of @ontoportal/agroportal we defined this strategy:

• https://github.com/agroportal/project-management/issues/312

And we plan to proceed it current January-February 2023.

I'm also available to give support and help for any of those who want.

[jonquet]

Totally clear to me. Thanks @syphax-bouazzouni. Are the others align on this? Can each team describe their strategy in a separate issue and point to it from here?

[rasmi-aw]

Well i agree on that...

[syphax-bouazzouni]

Done for Agroportal, it was easier than planned because it was only a matter of submitting a ticket to GitHub support to reroute our forks here: https://support.github.com/request/fork (nothing was lost and was done in one day), more detail can be found here https://github.com/agroportal/project-management/issues/312#issuecomment-1400025245

[syphax-bouazzouni]

Work done for IndustryPortal and BiodivPortal. Thanks, @RaimiSol and @Bouchemel-Nasreddine

[syphax-bouazzouni]

Work done for EcoPortal. Thanks, @gturrisi-lifewatch and @manuelfiorelli.

[jvendetti]

@alexskr - with regard to the BioPortal codebase, I'm assuming that you'd want to sever all of the upstream connections from OntoPortal to BioPortal first? In other words, it doesn't make sense to me to have BioPortal's repositories as both upstream and downstream from OntoPortal at the same time.

[alexskr]

Done for BioPortal