Difference between revisions of "DE4A Multilingual Ontology Repository (MOR)"
m |
m |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | The main functionality of the MOR is to provide a ''' | + | The main functionality of the MOR is to provide a '''common understanding of the semantic and syntax''' of '''''canonical evidence types''''', '''''sets of additional parameters''''' of provisions and '''''code lists''''' used for the cross-border evidence exchange, by describing them and all the terms that compose them, which are represented by the MOR Term Syntaxis. It is also aimed to facilitate the interaction between users and the system in the language selected by users, so labels of graphical user interfaces are also included in the MOR and technical resources are provided to ease the implementation of such interfaces, |
− | + | === MOR Term Syntaxis === | |
+ | A '''<u>MOR Term</u>''' is represented by its '''type'''. There are '''''simple types''''', e.g., ''string'', and '''''complex types''''' that are composed by simple types and/or other complex types. Canonical evidence types, sets of additional parameters, code lists and the graphical user interface (GUI) are complex types. Other complex types are concepts defined by core vocabularies and domain ontologies that are reused for describing other complex types. Code lists correspond to a special complex type composed by terms that represent each of the code list values. | ||
− | Complex types are modelled as tree hierarchies of terms | + | Complex types are modelled as tree hierarchies of terms, so each MOR term is uniquely identified by a '''path''' (e.g., ''"BirthEvidence/Child''") that represent the position of that term within the hierarchy. The '''cardinality''' of a MOR term specifies the how many values of the term are allowed -none, at least one, at most one- to compose the value of the higher term. |
− | Each term is semantically described by a '''label''', '''description''' and an '''example''' in every EU official language, but only the label is mandatory. These properties can be automatically translated from the English version to the rest of the languages, so the resulting version is marked as "non-verified" until a domain expert reviews the automatic translation, when this mark is changed to "verified". | + | Each MOR term is semantically described by a '''label''', a '''description''' and an '''example''' in every EU official language, but only the label is mandatory. These properties can be automatically translated from the English version to the rest of the languages, so the resulting version is marked as "non-verified" until a domain expert reviews the automatic translation, when this mark is changed to "verified". |
− | + | === MOR Term Reusability === | |
+ | A MOR term can be defined by a reference to other MOR term in order to '''<code>inherit</code>''' the whole definition of the latter, but properties of the referencing term can be '''overload''' with a new value and new properties can be added as well. For example, the MOR term ''"BirthEvidence/Child''", which is part of the canonical evidence for birth, can refer to the MOR complex term "''/Person''", a concept defined by a core vocabulary, so the terms that compose the latter (generic-term) are composing the former (specific-term) by reuse, but labels and descriptions of the specif-term can be changed to refer a new-born person instead of a general person; it is also possible to add new MOR terms to the specific-term, e.g. "''BirthEvidence/Child/BirthMarks",'' that are not present in the generic-term. | ||
− | + | Besides, it is possible to define a code list by a reference to an '''external source''', such as a service URL with the corresponding parameters to retrieve the whole list of values in the corresponding language, however, this functionality is not piloted by the DE4A project. | |
− | + | === MOR GUI components === | |
− | + | Some client-side building blocks are provided by the<code>MOR</code>to automatically generate customizable user interfaces for any complex term in any EU official language. | |
− | |||
− | In | + | There are three use cases where the building blocks of the '''MOR GUI components''' can be of help: |
+ | |||
+ | * the '''''explicit request''''' functionality allows users, in a language of their choice, to select the country where each canonical evidence type required by the procedure is to be provided and, in case of existing more than one provider for a canonical evidence type in a selected country, to select the proper provider. Users can also see the information to be provided by each canonical evidence type according to its definition in the MOR in the selected language. | ||
+ | * the '''''preview''''' functionality allows users to see, in a language of their choice, the information of the canonical evidence issued by the corresponding competent authority before it is sent to the procedure portal that requested it, offering also the option to cancel the sending. Labels and descriptions of the canonical evidence attributes are shown in the selected language. Values of the canonical evidence attributes cannot be legally translated unless they correspond to a canonical code list; however, most of the other values are dates, names or numbers that do not require translation. This is of special interest when the preview is located at the ''evidence provider's countryside'', since the language at this side can be different from the language of the procedure that requires the cross-border evidence and the user could not properly understand the provider's language (e.g., for Birth evidence, the user was born in the provider's country coincidentally). When the preview is located at the ''evidence evaluator's countryside'' and the user cancels the incorporation of the canonical evidence to the procedure, the user has the option to manually upload the required evidence since, otherwise, the application might be rejected. '''''Audits''''' can also use this building block to help auditors to understand canonical evidences in any language. | ||
+ | * the '''''additional parameters''''' functionality allows users to fill out the list of additional parameters specified by a provider to request a canonical evidence type, which are shown in a language of users' choice. In this case, the type of the MOR terms used to define the additional parameters are the key to generate the proper input field in a web form (calendar, select list, text box, etc.). This is of special interest when the additional parameters have to be required at the evidence evaluator side, because the additional parameters are set by evidence providers and a building block like this one is a generic solution for any provider and parameter. This functionality is not piloted by the DE4A project. | ||
+ | |||
+ | The MOR GUI components are reusable and generic for any complex term and language, and any modification in MOR terms (change on or new canonical evidence type, additional parameter, code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and Cascade style-sheets (CSS), and Javascript is used for the logic of the componentes and their integration into portals of evidence evaluators and providers, so parties in the evidence exchange do not need to develop their own equivalent GUI components and their graphical style is used in the MOR GUI components. | ||
+ | |||
+ | On the other hand, portals of evidence evaluators and providers that have developed the abovementioned functionalities by their own, can easily incorporate the multilingual facilities of the MOR by using a HTML custom-attribute to include the identification path of the MOR simple term whose value is shown under the HTML element, a language selector and the MOR Javascript library. In this case, when the language changes, the MOR Javascript looks for the MOR custom-attribute over the HTML elements of the page and changes the text under the found HTML element to substitute the label of the specified MOR simple term in the previous language for its label in the current language. | ||
+ | |||
+ | |||
+ | |||
+ | The design and implementation of MOR is also documented here [https://github.com/de4a-eu/MOR] | ||
[[Category:Wip]] | [[Category:Wip]] |
Latest revision as of 09:56, 16 April 2023
The main functionality of the MOR is to provide a common understanding of the semantic and syntax of canonical evidence types, sets of additional parameters of provisions and code lists used for the cross-border evidence exchange, by describing them and all the terms that compose them, which are represented by the MOR Term Syntaxis. It is also aimed to facilitate the interaction between users and the system in the language selected by users, so labels of graphical user interfaces are also included in the MOR and technical resources are provided to ease the implementation of such interfaces,
MOR Term Syntaxis
A MOR Term is represented by its type. There are simple types, e.g., string, and complex types that are composed by simple types and/or other complex types. Canonical evidence types, sets of additional parameters, code lists and the graphical user interface (GUI) are complex types. Other complex types are concepts defined by core vocabularies and domain ontologies that are reused for describing other complex types. Code lists correspond to a special complex type composed by terms that represent each of the code list values.
Complex types are modelled as tree hierarchies of terms, so each MOR term is uniquely identified by a path (e.g., "BirthEvidence/Child") that represent the position of that term within the hierarchy. The cardinality of a MOR term specifies the how many values of the term are allowed -none, at least one, at most one- to compose the value of the higher term.
Each MOR term is semantically described by a label, a description and an example in every EU official language, but only the label is mandatory. These properties can be automatically translated from the English version to the rest of the languages, so the resulting version is marked as "non-verified" until a domain expert reviews the automatic translation, when this mark is changed to "verified".
MOR Term Reusability
A MOR term can be defined by a reference to other MOR term in order to inherit
the whole definition of the latter, but properties of the referencing term can be overload with a new value and new properties can be added as well. For example, the MOR term "BirthEvidence/Child", which is part of the canonical evidence for birth, can refer to the MOR complex term "/Person", a concept defined by a core vocabulary, so the terms that compose the latter (generic-term) are composing the former (specific-term) by reuse, but labels and descriptions of the specif-term can be changed to refer a new-born person instead of a general person; it is also possible to add new MOR terms to the specific-term, e.g. "BirthEvidence/Child/BirthMarks", that are not present in the generic-term.
Besides, it is possible to define a code list by a reference to an external source, such as a service URL with the corresponding parameters to retrieve the whole list of values in the corresponding language, however, this functionality is not piloted by the DE4A project.
MOR GUI components
Some client-side building blocks are provided by theMOR
to automatically generate customizable user interfaces for any complex term in any EU official language.
There are three use cases where the building blocks of the MOR GUI components can be of help:
- the explicit request functionality allows users, in a language of their choice, to select the country where each canonical evidence type required by the procedure is to be provided and, in case of existing more than one provider for a canonical evidence type in a selected country, to select the proper provider. Users can also see the information to be provided by each canonical evidence type according to its definition in the MOR in the selected language.
- the preview functionality allows users to see, in a language of their choice, the information of the canonical evidence issued by the corresponding competent authority before it is sent to the procedure portal that requested it, offering also the option to cancel the sending. Labels and descriptions of the canonical evidence attributes are shown in the selected language. Values of the canonical evidence attributes cannot be legally translated unless they correspond to a canonical code list; however, most of the other values are dates, names or numbers that do not require translation. This is of special interest when the preview is located at the evidence provider's countryside, since the language at this side can be different from the language of the procedure that requires the cross-border evidence and the user could not properly understand the provider's language (e.g., for Birth evidence, the user was born in the provider's country coincidentally). When the preview is located at the evidence evaluator's countryside and the user cancels the incorporation of the canonical evidence to the procedure, the user has the option to manually upload the required evidence since, otherwise, the application might be rejected. Audits can also use this building block to help auditors to understand canonical evidences in any language.
- the additional parameters functionality allows users to fill out the list of additional parameters specified by a provider to request a canonical evidence type, which are shown in a language of users' choice. In this case, the type of the MOR terms used to define the additional parameters are the key to generate the proper input field in a web form (calendar, select list, text box, etc.). This is of special interest when the additional parameters have to be required at the evidence evaluator side, because the additional parameters are set by evidence providers and a building block like this one is a generic solution for any provider and parameter. This functionality is not piloted by the DE4A project.
The MOR GUI components are reusable and generic for any complex term and language, and any modification in MOR terms (change on or new canonical evidence type, additional parameter, code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and Cascade style-sheets (CSS), and Javascript is used for the logic of the componentes and their integration into portals of evidence evaluators and providers, so parties in the evidence exchange do not need to develop their own equivalent GUI components and their graphical style is used in the MOR GUI components.
On the other hand, portals of evidence evaluators and providers that have developed the abovementioned functionalities by their own, can easily incorporate the multilingual facilities of the MOR by using a HTML custom-attribute to include the identification path of the MOR simple term whose value is shown under the HTML element, a language selector and the MOR Javascript library. In this case, when the language changes, the MOR Javascript looks for the MOR custom-attribute over the HTML elements of the page and changes the text under the found HTML element to substitute the label of the specified MOR simple term in the previous language for its label in the current language.
The design and implementation of MOR is also documented here [1]