DE4A Multilingual Ontology Repository (MOR)

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.

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 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 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" (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.

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 use cases where this functionality can be of help:

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