Difference between revisions of "DE4A Multilingual Ontology Repository (MOR)"

From DE4A
Jump to navigation Jump to search
(Adapted to 2nd iteration)
m
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The main functionality of the MOR is to provide a '''<code><small>common understanding of the semantic and syntax</small></code>''' 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.
+
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,
  
The syntax of each 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 and code lists are complex types. Other complex types are concepts defined by core vocabularies and domain ontologies that are reused for describing canonical evidence types and sets of additional parameters. Code lists correspond to an special type composed by terms that represent each of the code list values.
+
=== 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., so each term is uniquely identify by a '''path''' (e.g. ''"BirthEvidence/Child''") that represent the position of that term within the hierarchy. The '''cardinality''' of the 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.
+
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".
  
For '''reusability''' of term descriptions, a term can be defined by a reference to other term in order to '''<code>inherit</code>''' the whole definition of the latter, unless some property is '''overload''' with a new value in the referencing term. For example, the complex term ''"BirthEvidence/Child''" can refer to the complex term "''/Person''", but then labels and descriptions are about persons instead of new-born persons; this can be changed by including the labels and descriptions in the "''/BirthEvidence/Child''" term definition with the proper texts. For code lists, it is possible to substitute the property with the list of terms that represent each of the code list values 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 in the project.
+
=== 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.  
  
Although the main functionality of the MOR is to provide a common understanding of the semantic and syntax of canonical evidence types, additional parameters and code lists, the <code>MOR can also be used to automatically generate customizable user interfaces for any complex term in any EU official language</code>. There are three cases where this functionality can be of help:
+
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.
  
* the '''''explicit request''''' functionality should inform the user on the information to be request as evidence and allow him to choose either to use the system or manually allow the evidence, so the MOR can help to create a building block to generate such a user interface for any canonical evidence type and language.
+
=== MOR GUI components ===
* the '''''preview''''' functionality should show the user the evidence to be incorporated to the procedure, so the MOR can help to create a building block to generate such a user interface for any canonical evidence type and language; '''''audits''''' can also use this building block to help auditors to understand the canonical evidence in any language. This is of special interest when the preview is located at the data provider's country side, 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 understand the provider's language (e.g. for Birth evidence, the user was born in the provider's country coincidentally). Values of the canonical evidence attributes cannot be legally translated unless they correspond to a canonical code list, however most of such values are dates, names or numbers that do not require translation. When the preview is located at the data evaluator's country side,
+
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.  
* the '''''additional parameters''''' functionality requires to request the user some fields through a web form, so the MOR can help to create a building block for generating such a web form for any set of additional parameters and language. In this case, the type of the terms are the key to generate the proper input field in the 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 the evidence provider.
 
  
In any case, the MOR building blocks have the advantage to be reusable and generic for any complex term and language, so parties in the evidence exchange do not need to develop their own equivalent components, and any modification in MOR is automatically available though the MOR building blocks. For a proper reusability of these building blocks, they are graphically customizable by Dynamic HTML and cascade style-sheets (CSS).
+
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 theMORto 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]