Content

2.1. Core Criterion and Core Evidence Vocabulary

The EB Information Model is based on the ISA2 SEMIC Core Criterion and Core Evidence Vocabulary (CCCEV) v2.0. The CCCEV is designed to support the exchange of information between organisations defining requirements and organisations responding to these requirements by means of evidence types. The OOTS generic metadata model adopts the CCCEV and this specification describes the Application Profile for the EB. 

The CCCEV contains two basic and complementary core concepts:

  • The Requirement, which is used as the basis for making a judgment or decision, e.g. a requirement set in a public tender or a condition that has to be fulfilled for a public service to be executed;
  • The Evidence Type, which proves that something else exists or is true. In particular, an evidence is used to prove that a specific requirement is met by someone or by something.


Information Model of the EB


2.2. Requirement Model

One of the central concepts of the Evidence Broker is the ‘Requirement’. It is a condition or prerequisite that someone requests and someone else has to meet.

The requirement is realised by three concrete types of requirements: The Information Requirement, the Criterion and the Constraint.

  • The Information Requirement is to be seen as a request for data that proves one or more facts of the real world, or that leads to the source of such a proof.
  • The Criterion is to be seen as a condition that will be evaluated.

  • The Constraint is a limitation imposed on any type of requirement or on an element defined inside a requirement.

2.3. Evidence Type Model

Each requirement is linked with one or more Evidence Type Lists of Evidence Types. An Evidence Type List is satisfied, if and only if, for all included Evidence Types in this List, corresponding to conformant Evidence(s), are provided. The Evidence Type List describes thus an AND condition on the different Evidence Types within the list and an OR condition between two or more Evidence Type Lists. Combinations of alternative Evidence Type Lists can be provided for a respondent of a Requirement to choose amongst them. The following behavior is supported by the EB Mechanism:

  • To fulfill a 'Requirement' at least one Evidence for each Evidence Type specified in one Evidence Type List MUST be provided.
  • The user can select an 'Evidence Type List' amongst the ones proposed by the Evidence Broker. Thus, 
    • Evidence Type Lists must have at least one Evidence Type.
    • Evidence Types of an Evidence Type List are combined via the logic operator ‘AND’.
    • Evidence Type Lists that fulfill the same Requirement are combined via the logic operator ‘OR’.
  • The 'Evidence Types' are described in detail with respect to their jurisdiction level.
  • The Evidence is an instance of an Evidence Types that provides the means to support responses to Requirements.

The EB holds a mapping between the Requirements and their associated Evidence Type Lists and Evidence Types that are able to prove these requirements. The mapping can be done either nationally or it can be harmonized among  MS (e.g. if an agreed pan-European standard is used as Evidence Type).  An Evidence instance that is requested and provided throughout the OOTS Evidence Exchange process should refer to its corresponding Evidence Type.

References

ISA2 SEMIC The Core Criterion and Core Evidence Vocabulary (CCCEV). https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/core-criterion-and-core-evidence-vocabulary 

  • No labels