Modeling Project Spaces: new "Project" entity or "Communities" extension

[lcodo]

"Project spaces" need to be modeled.
From user's perspective, they are customizable areas on a dedicated section of OEB website with descriptive metadata and grouping a set of benchmarking events. So formally, they could be considered a "Community". Yet, in some cases, projects may also group actual communities from different research domains.

Examples:

• "DREAM" space project
  • "Drug Resistance DREAM community"
  • "IPC DREAM community"
  • [...]
• "euCanImage" space project
  • "euCanImage" community

2 proposed strategies for modeling "Project spaces":

1. option A: creating a new "Projects" collection, with some fields covering common properties and with references to the list of associated communities. In most cases, "Projects" would link to a single community
2. option B: creating a new type of "Communities" or super-class of it.

During 11/02/22 internal meeting, option A was a priori preferred, but discussion is open.

[jmfernandez]

In case we create the concept of Project, should it be a traversal one, where each community can appear on 0 or more projects?

If it is so, who are the responsible of the projects? Are the administrator, or are the community managers of all the communities appearing at the project? How the governance should be?

And last, should the Projects have their own separate set of identifiers?

I'm moving it right now to "later", although it should be done for data model 2.1.