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

From DE4A
Jump to navigation Jump to search
m
Line 16: Line 16:
  
 
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 cascade style-sheets (CSS).
 +
[[Category:Wip]]

Revision as of 16:18, 14 February 2022

The main functionality of the MOR is to provide a common understanding of the semantic and syntax 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 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.

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.

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 inherit 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.

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 MOR can also be used to automatically generate customizable user interfaces for any complex term in any EU official language. 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 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 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.

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).