DE4A Multilingual Ontology Repository (MOR) - Revision history

Alberto.crespo at 08:56, 16 April 2023

2023-04-16T08:56:57Z

Anarosa.guzman: Review and inclusion of MOR javascript for existing portals

2023-01-20T10:16:59Z

Review and inclusion of MOR javascript for existing portals

Thasmee.karunaratne at 10:42, 13 December 2022

2022-12-13T10:42:22Z

Anarosa.guzman at 11:28, 24 March 2022

2022-03-24T11:28:29Z

Anarosa.guzman at 11:25, 24 March 2022

2022-03-24T11:25:20Z

Anarosa.guzman at 11:10, 24 March 2022

2022-03-24T11:10:34Z

Anarosa.guzman at 11:09, 24 March 2022

2022-03-24T11:09:07Z

Anarosa.guzman at 11:08, 24 March 2022

2022-03-24T11:08:51Z

Anarosa.guzman at 08:33, 24 March 2022

2022-03-24T08:33:13Z

Anarosa.guzman: Adapted to 2nd iteration

2022-03-23T12:47:16Z

Adapted to 2nd iteration

← Older revision		Revision as of 08:56, 16 April 2023
Line 28:		Line 28:


−	The design and implementation of MOR is also documented here [https://github.com/de4a-~~wp3~~/MOR]	+	The design and implementation of MOR is also documented here [https://github.com/de4a-eu/MOR]
	[[Category:Wip]]		[[Category:Wip]]

@@ 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 ===
-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''" (sub-term) can refer to the complex term "''/Person''" (super-term), 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; it is also possible to add more terms to the sub-term than the inherited ones from the super-term. 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 by the project.
+=== MOR Term Reusability ===
-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 use 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.
 The design and implementation of MOR is also documented here [https://github.com/de4a-wp3/MOR]
 [[Category:Wip]]

← Older revision		Revision as of 10:42, 13 December 2022
Line 16:		Line 16:

	There is a MOR GUI component that implements each of the aforementioned use cases "explicit request" and "preview"; the MOR GUI component for "additional parameters" is not piloted by DE4A. 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 or code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and cascade style-sheets (CSS), so parties in the evidence exchange do not need to develop their own equivalent GUI components but customize and integrate the MOR GUI components in their portals.		There is a MOR GUI component that implements each of the aforementioned use cases "explicit request" and "preview"; the MOR GUI component for "additional parameters" is not piloted by DE4A. 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 or code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and cascade style-sheets (CSS), so parties in the evidence exchange do not need to develop their own equivalent GUI components but customize and integrate the MOR GUI components in their portals.
		+
		+
		+	The design and implementation of MOR is also documented here [https://github.com/de4a-wp3/MOR]
	[[Category:Wip]]		[[Category:Wip]]

@@ Line 7: / Line 7: @@
 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".
-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''" (sub-term) can refer to the complex term "''/Person''" (super-term), 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; it is also possible to add more terms to the sub-term than the inherited from the super-term. 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 by the project.
+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''" (sub-term) can refer to the complex term "''/Person''" (super-term), 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; it is also possible to add more terms to the sub-term than the inherited ones from the super-term. 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 by the project.
 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 use cases where this functionality can be of help:

@@ Line 15: / Line 15: @@
 * 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.
-There is a MOR GUI component that implements each of the aforementioned three use cases. 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 or code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and cascade style-sheets (CSS), so parties in the evidence exchange do not need to develop their own equivalent GUI components but customize and integrate the MOR GUI components in their portals.
+There is a MOR GUI component that implements each of the aforementioned use cases "explicit request" and "preview"; the MOR GUI component for "additional parameters" is not piloted by DE4A. 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 or code list) is automatically available. The MOR GUI components are graphically customizable by Dynamic HTML and cascade style-sheets (CSS), so parties in the evidence exchange do not need to develop their own equivalent GUI components but customize and integrate the MOR GUI components in their portals.
 [[Category:Wip]]

@@ 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''', '''additional parameters''' of provisions and '''code lists''' used for the cross-border evidence exchange, by describing all the terms that compose them.
+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 syntax of each term is represented by its '''type'''. There are '''''simple types''''', e.g. ''string'', and '''''complex types''''' that are compose 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 that also includes a property with the list of terms that represent each of the code list values.
+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.
-Complex terms are defined as complex types and modelled as tree hierarchies of terms., so each term is uniquely identify by a '''path''' that represent the position of that term within a complex term hierarchy. An '''optionality''' property specifies if the term value is mandatory for composing the value of the higher term.
+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.
 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".
-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.
+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.
 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:
-* the '''''explicit request''''' functionality should inform the user on the information to be request as evidence, so the MOR can help to create a building block to generate such a user interface for any canonical evidence type and language.
+* 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.
-* 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 space is located at the evidence provider side, since there 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.In this case, values of the canonical evidence attributes cannot be legally translated unless they are from a canonical code list, but most of such values are dates, names or numbers that do not require translation.
+* 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,
-* the '''''additional parameters''''' functionality requires to request the user some fields through a form, so the MOR can help to create a building block to generate such a from 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 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.
+* 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 cascade style-sheets (CSS).
+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).
 [[Category:Wip]]