Membership of an OOR in a Federation is driven by shared interest (18A3)

A federation typically maps to a community of interest which is often a vertically specialized domain (e.g. Healthcare, Ocean Science, Automotive, Telco etc.) (18A4)

During development Ontological content may be authored and stored in a local OOR instance (18A5)

Finished Ontological content may be promoted / deployed to a shared community repo. This process should have human review and approval process (18A6)

Changes to shared community repo are notified to interested subscribers (other authors) (18A7)

Local repos may synchronize with communtiy repo and community repo may synchronize with root repo periodically (18A8)

Root repo will not have replica of all community repos. It will only have the ontological content that is common to more than one community. It will also have a catalog of community repos and what they have to offer. (18A9)

There will be a process to request that certain ontological content be promoted / deployed to root repo if it seems valuable to more than one community. (18AA)

There will be a broader and tighter governance process at the root repo and will likely have reviewers from multipel communities (18AB)

Federated can also imply peer or equal access authority - peer type of organizations sharing access to the repository. Distributed repository example can be more general if FarrukhNajmi could kindly modify the diagram (visual) to include at least one place where the author can write to more than one local repository - this would imply distributed repository for a given ontology and not necessarily all local only, some could be remote. (1930)

Could we get more visuals for conceptual architectures that are implementation oriented with known IT elements and also showing Gaps that exist for repository architecture to be completed, at least for simply authenticated open repositories? (192Z)