Discussion #2337

Updated by Daniele Francioli over 5 years ago

<p><span style="color:#FFFFFF;"><span style="background-color: rgb(255, 140, 0);">## DRAFT ##</span></span></p>

<p>This discussion has been created in order to find the rigth architecture for the &quot;Register Federation&quot;. The following paragraphs show a proposal for the different features related to the Register Federation.</p>

<p>The central tool of the federation is the Register of Registers (RoR), where <strong>metadata</strong> related to the Registers and Register items are indexed. The RoR does not contain the registers data but only metadata, reference to registers/register items and relations/links between them.</p>

<h4>Definitions:</h4>

<p>Local registry: a member state&#39;s registry or an european institution&#39; registry. Also indicatedad &quot;local level&quot;.</p>

<p>RoR: register of registers - The central register handling the register federation.</p>

<p>&nbsp;</p>

<h2>Metadata for the Register Federation</h2>

<p>Below you can find a list of metadata elements for the federation.</p>

<ul>
<li><strong>Registry</strong>

<ul>
<li><strong>Basic metadata</strong>: URI, description, registry manager;</li>
<li><strong>API</strong>: which operations are supported by this Registry. This is a list and a description of operations that can be performed by the Registry. A link to the Registry&#39;s API entry point is provided.</li>
</ul>
</li>
<li><strong>Registers</strong>
<ul>
<li><strong>Basic metadata</strong>: URI, description, owner, registermanager, control body, contact point;</li>
</ul>
</li>
<li><strong>Extension information:</strong> information to relate the elements in the different registers. Examples: <span style="font-family:courier new,courier,monospace;">extends(source,target)</span> - <span style="font-family:courier new,courier,monospace;">extends(http://ms_registry/codelist/abc,http://inspire.ec.europa.eu/codelist/def)</span></li>
</ul>

<p>&nbsp;</p>

<p>From an architectural point of view, there are 2 way of setting the RoR: a centralized approach and a distributed approach.</p>

<h2>1. Centralized approach</h2>

<p>The cantralized approach keeps all the federation information in the RoR at a centralized level. This means that all the stakeholders has to provide the information for the federation using the central API provided by the RoR. Below there are the proposed RoR API for this scenario.</p>

<ul>
<li>Searching operations:
<ul>
<li>GetRegistries() : Collection&lt;RegistryId&gt; - Gets a list of registries registered in the federation;</li>
<li>GetRegisters(r : RegistryId) : Collection&lt;RegisterId&gt; - Gets a list of federated registers contained in a registry (not all registers in a registry need to be part of the federation)</li>
<li>GetRegisterExtensions(r : RegisterId) : Collection&lt;RegisterId&gt; - Gets all the extensions of a specific register</li>
<li>GetItemExtensions(i : ItemId) : Collection&lt;ItemId&gt; - Gets all the extensions of a specific register item (e.g. extended values of a code list item)</li>
</ul>
</li>
<li>Indexing operations:
<ul>
<li>AddRegistry(r : RegistryDescription) : void - Adds a registry (incl. its metadata) to the federation</li>
<li>EditRegistry(rid : RegistryId, r : RegistryDescription) : void - Modifies registry metadata</li>
<li>RemoveRegistry(rid : RegistryId): void -&nbsp;Removed a registry from the federation</li>
<li>Adding/editing/removing registers, extension information etc. would be done through an update of the RegistryDescription. Alternatively, Add/Edit/Remove operations could also be provided for registers and extension information.</li>
</ul>
</li>
</ul>

<p><strong><span style="color:#008000;">PRO:</span></strong> with this approach, the Local Registries Register (e.g. a member state registry) register) does not need to provide the API. API for assessing the registry. Indeed, all the information will be registered in the federation by the local registries using the RoR API. Furthermore, no information related to the extension relations are stored at the local level (all centralized).</p>

<p><strong><span style="color:#B22222;">CON:</span></strong> any update to the Local Registers Register (e.g. addition or edit of an extension) shall be propagated to the RoR using its API.</p>

<p>&nbsp;</p>

<h2>2. Distributed approach</h2>

<p>The distributed approach keeps only the information related to the local registries APIs entry in the RoR at a centralized level. This means that the RoR will automatically connect to the local registies API and get the information.</p>

<ul>
<li>Searching operations:
<ul>
<li>all of these operations are provided by the local registries</li> register&lt;/li&gt;
</ul>
</li>
<li>Indexing operations:
<ul>
<li>AddRegistry(r : RegistryDescription) : void - Adds a registry (reference to the Registry&#39;s API) to the federation</li>
</ul>
</li>
</ul>

<p><strong><span style="color:#008000;">PRO:</span></strong> with this approach, the local registries register has no need to propagate the changes to the RoR because it automatically takes the information using the API provided by the local registries.</p> register.&lt;/p&gt;

<p><strong><span style="color:#B22222;">CON:</span></strong> the local registries register has to provide the API with all the agreed functionalities. Furthermore, with this approach the extension relations are store at local level.</p>

Back