Version 0.9.0

11 Key Decision Log

  • The UNCTAD’s Generic Database Builder (eRegistrations) system will be used as a reference system in describing the functional requirements.
  • 23.09.2021 - WG meeting, based on review recommendations made by Architecture WG, we decided to add API services or IT-specialists to create/modify/delete registry database schema.
  • 22.11.2021 - Coverage map chapter will be added to the document.
  • 28.02.2022 - Review comments incorporated to the main document (v1.1.0) 24.02.2022 (see below). Future consideration chapter updated based on reviewers comments. Recommendations not to be considered in this building block documented (see below)
Suggested Action/Reason
1. Incorporated in V1
2. Key Digital Functionalities.
I would add here capability to manage access to the Registry data
Yes, see requirement DRS-6
Modifications to be absorbed in this version
Sharing data with others is a function that was added to the requirements. See DRS-33
2. Key Digital Functionalities.
currently, my impression is that the Registration BB is optimised for entering and processing data and not for retrieval and usage. I see it as a missing capability requirement.
Registration BB functionality is described in another document. Pull (read) data functionality in Registration BB improved.
Modifications to be absorbed in this version:
1. add arrows to the drawing to reflect the two-way communication.
See data retrieval API Open API services descriptions for more information.
DRS-2. Foreign keys.
I am not sure, I can understand the way how FK-s suppose to work (see comment below in Appendix 2)
Databases in this concept are stored as tables, thus the foreign key works the same as in a structured database. In the Digital Registries user interface it must be possible to open another database by clicking on the ID of one database and all corresponding records from the other database will open. In API, the developers can decide how to use the Foreign key to improve the UX.
Modifications to be absorbed in this version:
We improved the functionality description.
1. does it includes Dropbox option to select from List of Values (LOV)? How can I define List values and how can I attach it to field in a form?
2. Does it includes option for hierarchy of List of Values, where selected value in one LOV defines subset of allowable options in another LOV?
1. yes, catalog/select values are used, however this is managed by client UI (Registration BB). Digital registries is storing data/ key of the list element. Catalogs are managed in Registration BB/ other BB.
2. Sub-catalogues function and the control could be added to Registration BB when required by the Use Case. Digital Registries BB contains Enum list validation option.
Modifications acceptable but to be taken up in future version
I was talking about the REST endpoint URL. The URL has a placeholder for version (marked as {version}). I believe it to be the version of the API being called, but the document throughout talks about DB schema version, and no mention of this version being the version of the API. That could create confusions on what the parameter "version" is.
Thank you for the clarification. Will be implemented in this version.
The system generates default API method endpoints automatically after each publish of the database schema. A new API service version is generated after each schema publish. Database schema version and API versions are in sync. I hope this clarifies the confusion.
3. Not to be considered
General recommendation.
Harmonize all URLs across all building blocks. The slide deck and the specs documents don't correspond very well and at times contradict. For example, the Purpose of the Registries BB isn't articulated in the Specs doc but appears only in the slide deck.
Not implemented.
Purpose is described in the specification and in the powerpoint. It is unclear what was expected.
2. Registries MUST adhere to core principles of data being Live, Reusable and Trustworthy.
Registry management principles would be another document - user manual, or best practices to build digital registries.
Some examples:
Registry SHALL support use of multiple data stores like RDBMs, NoSQL and Graph to represent the data representation across domains.
We are not restricting the support of any mentioned database types.
Registry MAY optionally support to do payload level encryption (especially for highly sensitive data) over transport layer to ensure backend services (beyond TLS termination) handle data securely.
This is solved by Information Mediator BB.
Section 7 states, this BB doesn't have internal workflows. But this BB MUST support meta data about workflows on who has attested the data.
Yes, metadata is like any data that can be added to the Digital Registries Database. Analyst can decide how to store the processing information.
Since APIs are available to access the digital registries, there is no need to have a separate data access mechanism for the administrators. It is important to use the same APIs in the user interface proposed for the administrators.
UI is needed for analysts to improve the UX. Same API will be used to create databases.
  1. 1.
I understood, that authors divided overall registration domain into two parts: Registration BB covers process of submitting applications and processing the data to make decision and here suppose to be a Registry usage part. However, I do not see here specifics about usage of registries. For example, usage of Registry may have complex access rules, requirements of fast access to large data sets etc. I do not see any discussion here on those matters
This BB is about creating and managing data. IAM BB for user rights and roles management is a separate BB. However the system has its own internal authorization system.
Internal ABAC has been specified in DRS-6.
Open API for data exchange has been described below.
According to Use Case, no large datasets available for storing.
Modifications not feasible.
  1. 1.
Should there not be an intro what “registry” is and why in some cultures there are different concepts for registries and databases?
I would also think that it would be appropriate to guide a potential reader to right choice of register, i.e more policy choice questions for the intro part
Registry is defined in the Glossary. Domain specific rules of registration are different, so there is no common principles how to build or manage a generic registry. This could be generated in the future.
Registry owner- Analyst has all the rights to decide the data set to be stored. Basic registry functionality has been added to the technology and described as requirements. The analyst has the opportunity to decide by him/herself what data to store in the Digital Registries BB.
The principles of traditional Registries management is not in the scope of this document.
See example domain specific principles here: UNCITRAL Legislative Guide on Key Principles of a Business Registry
  1. 1.
    Description -Digital Registries is simple to use.
This is true only if specific functional domain is properly embedded into the no-code platform as kinda of DSL. However, in case if I need to design complex models by myself, then usage of no-code platforms may be additional burden and bring too cumbersome development experience, which ultimately will decrease sustainability of the solution and increase TCO and even making kinda vendor-lock-in to the platform
With current task in hand, the use case is simple enough to be nicely fit into No-Code digital registry. In the future when we will find a domain and data set that needs something more complex, then we can analyze how to solve it.
It is always possible to use traditional methods to build registry databases if Digital registries is not suitable.
The training how to build a domain specific registry is the future challenge of next organizations.
A marketplace would help to solve these challenges. This spec enables to build any domain registry.
  1. 1.
    Key Digital Functionalities
this capability should include also metadata aka configuration schema of a Registry in order to configure schema in dev environment, test it in next environment and then deploy it to production. This capability should be shown here explicitly. Also automation is needed for that.
Yes , this is point nr 1 and 2. See more requirement DRS-10 for schema import and export.
Modifications not feasible.
  1. 1.
    (7) Import/export data from/to external files;
This capability should include also metadata aka configuration schema of a Registry in order to configure schema in dev environment, test it in next environment and then deploy it to production. This capability should be shown here explicitly. Also automation is needed for that.
Yes , this is point nr 1 and 2. See more requirement DRS-10 for schema import and export.
Modifications not feasible.
Does it includes option of pre-filling of forms based on Applicant context in the current registry as well as in other 3rd partied sources?
Pre-filling of forms is Registration BB functionality. User Interface is managed in Registration BB.
Digital registries has Triggers to prefill data fields in the database (ID, prefix etc. )
Modifications not feasible
in case of notaries there is a need for more complex schema of user rights as far as Notar is independent private sector entity
In this case Notary/ health worker is using Registries BB via Information Mediator. System must have basic User right management. Additional Roles may be added after IAM system is in place.
in complex organisations with implies requirement to have an organisational data here and to able to create permissions for positions in organisational units. Also, there is aspect of substitution in case of illness, vacations etc.
Yes, we must link the system with IAM BB where we will get those roles.
I would suggest to have similar abstraction for legal entity as well. Also, for relations between persons, legal entities, addresses etc. Otherwise it will be too complicated for analysts to model domains.
What would be the use case? the Digital registries allows to store any data.
Modifications not feasible
to create meaningful UI to use complex data, for example, from licensing domain using such generic schema will be just too complicated and cumbersome task. It will not fly globally.
Digital registries has capabilities to facilitate registry from any domain. If there is such a data schema that Digital Registres BB id not capable to facilitate, then traditional structured databases can be used instead.
Digital Registries functions well with the Mother and Child Program. It will take 15 minutes to create and publish a database for the program without writing any line of code.
General comment. I do not think, such generic level as it is now the specification will be helpful for practitioners let's say in Rwanda, Botswana, Ukraine, Moldova etc. It does not bring simplification. It is more like you have to learn some proprietary cumbersome language to make simple things in a very complicated manner.
Digital Registries capabilities are following no-code principles, thus no need to learn cumbersome languages.
However any IT system (including MS SQL and Oracle, My SQL) requires admin/analyst user who must learn the principles of maintaining and configuring the system. In this case we have envisioned this role to be Analyst. Additional specifications to this BB can be added in the next iteration. Currently it is MVP and focused on one domain. Next , when new domains will be added, then we can add additional flesh on the bones. The system has capabilities for admins and analyst to build databases, sometimes even temporary registries and this is the best tool for it.
Should maybe integrity of registration process itself merit special concern depending on the registry in question and the obligation of owner to guarantee the correctness of data, e.g. think of property database and potential abuse?
This question requires additional debate. According to the methodology the focus is in the Use Case of Mother and Child Program and related processes. Let’s not focus on all things at once. Next iteration we can add processes and use cases. So far the Digital Registries BB fulfilled the needs of the Domain process.
normally, database may contain several containers/tables, which may have also its own key. Like in case of RDBMS foreign key would have reference to database, table and record. Here is only 2 key. Would it be sufficient?
Noted. Currently it is sufficient.
Does not clarify how transit is secured. (Encryption of a payload can be added as a "May")
Information transit between building blocks is governed by Information Mediator BB. All information transit is encrypted between the BB-s. See more in Information Mediator. Decision: Added a comment on transit to this requireme
Copyright © 2022