Abstract

Introduction

This document describes the Core Criterion and Core Evidence Vocabulary (CCCEV). Similarly to all the Core Vocabularies, CCCEV is "a context-neutral data model that captures the fundamental characteristics of an entity". A Core Vocabulary specifies a semantic data model covering a set of use cases across domains. The specification consists of terms with a minimal set of constraints (recommended codelists, usage guidelines, etc.).

The Core Criterion and Core Evidence Vocabulary is designed to support the exchange of information between organisations or persons (more generally Agents) defining Requirements and organisations or persons responding to these Requirements by means of structured or unstructured Evidences.

CCCEV contains two basic and complementary core concepts:

• the Requirement, a broad notion encompassing all forms of requests for information, that is often, but not necessarily, made with the objective to use it as a basis for making a judgement or decision; and
• the Evidence, the data proving or disproving that a specific Requirement is met by someone or something, and thus has been fulfilled.

Although CCCEV shapes a general framework around these core concepts, implementers have to make decisions on how the framework is actually used by further elaborating the Core Vocabulary to make it applicable in their specific context.

Status

This Core Vocabulary has the status SEMIC Candidate Recommendation published at 2024-01-31.

Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog.

License

Copyright © 2024 European Union. All material in this repository is published under the license CC-BY 4.0, unless explicitly otherwise mentioned.

Terminology

A Core Vocabulary (CV) is a basic, reusable and extensible data specification that captures the fundamental characteristics of an entity in a context-neutral fashion. Its main objective is to provide terms to be reused in the broadest possible context. More information can be found on the SEMIC Style Guide.

Overview

Main Entities

Constraint

Definition

Limitation applied to an Information Concept.

Usage Note

Constraints are requirements in themselves, since they impose prerequisites which influence the definition, use and/or fulfilment of the requirement. They represent hard conditions such as minimum or maximum expressions which can be used to evaluate pieces of information, the required age, income, involvement in activities, etc. An example from the eProcurement domain is a threshold as the minimum turnover required by the buying organisation to select the candidates. Note that CCCEV does not provide any specific guidance on when which kind of Requirement should be used. Users of this vocabulary should make decisions on this topic in their specific context.

Subclass of

Requirement

Properties

For this entity the following properties are defined: constrains .

	Property	Range	Card	Definition	Usage
	constrains	Information Concept	0..*	Information Concept about which a Constraint expresses a limitation.	Information Concepts are tools to make Requirements more machine processable: they allow to provide more detail about a Requirement. This way, Constraints can be made very precise, namely the limit that must be achieved, is a limit on the value for the associated Information Concept. For example, the Information Concept would be the age of a person and the Constraint would be the required age in the context of a specific evaluation.

Criterion

Definition

Condition for evaluation or assessment.

Usage Note

In general, Criteria are used for comparison, filtering or selection purposes. Criteria usually set minimum conditions (e.g. limits, intervals, thresholds, etc.) that need to be met in order to pass the requirements or to fulfil them to a certain degree or quality. The concept of Criteria is broader than the concept of Constraint since it covers more usages. The evaluation of the fulfilment is usually supported by the provision of Evidence. For example in the eProcurement domain, the eProcurement Ontology defines different subclasses of Criterion such as exclusion grounds, selection criteria or award criteria. A concrete example of a Criterion is 'participation in a criminal organisation' which could also be considered as an exclusion ground criterion in the procurement domain or for requiring a public service.

Subclass of

Requirement

Properties

For this entity the following properties are defined: bias , weight , weighting consideration description , weighting type .

	Property	Range	Card	Definition	Usage
	bias	Decimal	0..*	Parameter used to adjust the evaluation of the Criterion.	The bias parameter tries to correct a systematic error. For example in procurement, a home bias corresponds to the "presence of local preferences distorting international specialisation and resource allocation". When quantified, this systematic error can be removed.
	weight	Decimal	0..*	Relative importance of the Criterion.	The weight must be between 0 and 1. Usually, all Criteria can be integrated within a weighted sum equal to 1.
	weighting consideration description	String	0..*	Explanation of how the weighting of a Criterion is to be used.	This description gives the view of the creator of the Criterion weights on how to interpret and use them during the evaluation process.
	weighting type	Code	0..*	Indication of how the weight should be interpreted in a complex evaluation expression, e.g. as a percentage in an evaluation expression.	An existing codelist which can be used is OP's Number weigth controlled vocabulary

Evidence

Definition

Proof that a Requirement is met.

Usage Note

The class Evidence provides the means to support responses to Criteria or to a concrete Information Requirement or to an Information Concept inside an Information Requirement. The proof described by an Evidence can [1] verify a claim (i.e. is it true that John is 25, yes/no), [2] prove a condition (i.e. is John 18+, yes/no), or [3] simply provide data (i.e. the age of a person, namely 25). The proof can be given through documents or extracts of base registries, independently from its structure, format or medium used to exchange it: a pdf document, a video, a recording, etc.

Properties

For this entity the following properties are defined: confidentiality level type , is about , is conformant to , is created by , is issued by , is provided by , supports concept , supports requirement , supports value , validity period .

	Property	Range	Card	Definition	Usage
	confidentiality level type	Code	0..*	Security classification assigned to an Evidence e.g. classified, sensitive, public.	Classifications should be defined by an organisation/country as an outcome of a security assessment.
	is about	Agent	0..*	Agent that is the subject in the provided Evidence.
	is conformant to	Evidence Type	0..*	Evidence Type that specifies characteristics of the Evidence.	Examples of characteristics could be the layout or the configuration of the Evidence.
	is created by	Agent	0..*	Agent that produces the Evidence.	The production of evidence could involve the generation of a document or the extraction of data from a database.
	is issued by	Agent	0..*	Agent legally responsible for the Evidence, e.g. a legal authority.	This property captures cases such as when a legal authority is responsible for the regulation about an Evidence (e.g. a ministry).
	is provided by	Agent	0..*	Agent that transmits the Evidence.	Agents transmitting Evidence are usually the Agents issuing the Evidence or service providers acting on behalf of the issuing Agents such as software developer companies. The Evidence provisioning might pass through a chain of providers. Implementers have to define which providers are to ba shared or which not.
	supports concept	Information Concept	0..*	Information Concept providing facts found/inferred from the Evidence.	Examples of Information Concepts are values found explictly in the evidence such as a birth date or information derived from the Evidence such as "I am older that 18 years".
	supports requirement	Requirement	0..*	Requirement for which the Evidence provides proof.
	supports value	Supported Value	0..*	Supported Value that the Evidence contains.
	validity period	Period of Time	0..*	Period of Time during which the Evidence holds true or has force.

Evidence Type

Definition

Information about the characteristics of an Evidence.

Usage Note

The Evidence Type and the characteristics it describes are not concrete individual responses to a Requirement (i.e. Evidence), but descriptions about the desired form, content, source and/or other characteristics that an actual response should have and provide (e.g. membership of a class of Evidences).

Properties

For this entity the following properties are defined: evidence type classification , identifier , is specified in , issuing place , validity period constraint .

	Property	Range	Card	Definition	Usage
	evidence type classification	Code	0..*	Category to which the Evidence Type belongs.	The categories agreed are left open but could for example specify the layout and content expected for an Evidence.
	identifier	Literal	0..*	Unambiguous reference to the Evidence Type.
	is specified in	Evidence Type List	0..*	Evidence Type List in which the Evidence Type is included.
	issuing place	Location	0..*	Refers to the Location where an Evidence Type is issued.	E.g. Belgian ID cards are issued in Belgium.
	validity period constraint	Period of Time	0..*	Temporal condition on the validity period of the Evidence Type.	E.g. A Belgian birth evidence is valid for X months after emission. To express constraints on the validity period that must hold when assessing the evidence (e.g. the certificate of good conduct cannot be issued more than 3 months ago), we refer to the Constraint class.

Evidence Type List

Definition

Group of Evidence Types for conforming to a Requirement.

Usage Note

An Evidence Type List is satisfied, if and only if, for all included Evidence Types in this List, corresponding conformant Evidence(s) are supporting the Requirement having this List. 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 Lists can be provided for a respondent of a Requirement to choose amongst them.

Properties

For this entity the following properties are defined: description , identifier , name , specifies evidence type .

	Property	Range	Card	Definition	Usage
	description	String	0..*	Short explanation supporting the understanding of the Evidence Type List.	The explanation can include information about the nature, attributes, uses or any other additional information about the Evidence Type List.
	identifier	Literal	0..*	Unambiguous reference to the Evidence Type List.
	name	String	0..*	Name of the Evidence Type List.
	specifies evidence type	Evidence Type	0..*	Evidence Type included in this Evidence Type List.

Information Concept

Definition

Piece of information that the Evidence provides or the Requirement needs.

Usage Note

The Information Concept class offers the ability to describe conceptually the Requirements and provided facts in Evidences. In complementarity with the Supported Value class, this is a (first) step towards facilitating the assessment of the requirements in an automated way based on the Evidence provided.

Properties

For this entity the following properties are defined: description , expression of expected value , identifier , name , type .

	Property	Range	Card	Definition	Usage
	description	String	0..*	Short explanation supporting the understanding of the Information Concept.	The explanation can include information about the nature, attributes, uses or any other additional information about the Information Concept.
	expression of expected value	Literal	0..*	Formulation in a formal language of the expected value(s) for the Information Concept which is aligned with the concepts from the Requirements defined and must be respected by the supplied Supported Values .	The property encapsulates all kind of expectations on the required and provided values one could have. This may range from representational expectations such as the type (e.g. the value is expected to be a xsd:decimal) to expectations that reduce the allowed value range. Commonly this is done using min or max bounderary expressions (e.g. the maximum value is 1 Million Euro). Other usage could be to harmonise the supplied values (e.g. rounding, turning to percentages) to facilitate further processing. Implementers are free to use their own approach for defining the expected values in more details. For instance, this can be by defining their own datatypes extending or encapsulating common xsd datatypes. But also by using more complex languages such as XPath, Object Constraint Language (OCL), JavaScript and Rule Interchange Format (RIF). Because of this freedom, implementers are recommended to well-document their usage of this property (and related information).
	identifier	Literal	0..*	Unambiguous reference to the Information Concept.
	name	String	0..*	Name of the Information Concept.
	type	Code	0..*	Category to which the Information Concept belongs.	In addition to the expression of the expected value, the type classification can be used to express the kind of value the information concept is processing. This can be primitive tupes such as a date or a string, but also more business domain terminology such as age or number of employees. It is recommended to well-document the usage of the property.

Reference Framework

Definition

Legislation or official policy from which Requirements are derived.

Usage Note

Usual Reference Frameworks are legal and non-legal specifications. Examples include procedures, tendering legislation, etc.

Properties

For this entity the following properties are defined: identifier .

	Property	Range	Card	Definition	Usage
	identifier	Literal	0..*	An unambiguous reference to a Reference Framework.

Requirement

Definition

Condition or prerequisite that is to be proven by Evidence.

Usage Note

Requirement is a generic class representing any type of prerequisite that may be desired, needed or imposed as an obligation. CCCEV recommends to not use the Requirement class directly, but rather a more semantically-enriched subclass such as Criterion, Information Requirement or Constraint. Also note that the Requirement class is specified at a more abstract level and is not to be used as the instantiation of a Requirement for a specific Agent. The European Directive on services in the internal market defines requirement as any obligation, prohibition, condition or limit provided for in the laws, regulations or administrative provisions of the Member States or in consequence of case-law, administrative practice, the rules of professional bodies, or the collective rules of professional associations or other professional organisations, adopted in the exercise of their legal autonomy.

Properties

For this entity the following properties are defined: description , has concept , has evidence type list , has qualified relation , has requirement , has supporting evidence , identifier , is derived from , is issued by , is requirement of , name , type .

	Property	Range	Card	Definition	Usage
	description	String	0..*	A short explanation supporting the understanding of the Requirement.	The explanation can include information about the nature, attributes, uses or any other additional information about the Requirement.
	has concept	Information Concept	0..*	Information Concept for which a value is expected by the Requirement.	Information Concepts defined for specific Requirements also represent the basis for specifying the Supported Value an Evidence should provide.
	has evidence type list	Evidence Type List	0..*	Evidence Type List that specifies the Evidence Types that are needed to meet the Requirement.	One or several Lists of Evidence Types can support a Requirement. At least one of them must be satisfied by the response to the Requirement.
	has qualified relation	Requirement	0..*	Described and/or categorised relation to another Requirement.	This property leaves the possiblity to define a qualified relation from Requirement to Information Requirement or Constraint as well as a qualified relation from Requirement to Requirement. A use case would be to specialize an EU requirement in Member States' specific requirements.
	has requirement	Requirement	0..*	A more specific Requirement that is part of the Requirement.
	has supporting evidence	Evidence	0..*	Evidence that supplies information, proof or support for the Requirement.
	identifier	Literal	0..*	Unambiguous reference to a Requirement.
	is derived from	Reference Framework	0..*	Reference Framework on which the Requirement is based, such as a law or regulation.	Note that a Requirement can have several Reference Frameworks from which it is derived.
	is issued by	Agent	0..*	Agent that has published the Requirement.
	is requirement of	Requirement	0..*	A reference between a sub-Requirement and its parent Requirement.	The relation between a parent Requirement and a sub-Requirement can be complex. Therefore, qualified relations (see hasQualifiedRelation) can be used to represent this relationship on its own and qualify it with additional information such as a date, a place. This is left to implementers. In the case where the purpose is to link the two Requirements without additional information, the simple relationship as proposed here can be directly used.
	name	String	0..*	Name of the Requirement.
	type	Code	0..*	Category to which the Requirement belongs.

Supportive Entities

Period of Time

Definition

A temporal entity with non-zero extent or duration.

Usage Note

The value of the start time and end time properties should be different, and/or a duration should be given.

Properties

For this entity the following properties are defined: duration , endtime , starttime .

	Property	Range	Card	Definition	Usage
	duration	Duration	0..*	Extent of the Period of Time.	Amount of time between start time and end time.
	endtime	Instant	0..*	Time instant at which the Period was terminated.	For example, the property ends the duration during which an Evidence Type or an Evidence is considered valid. The duration must be equal to the time between the starttime and endtime.
	starttime	Instant	0..*	Time instant at which the Period was initiated.	For example, the property starts the duration during which an Evidence Type or an Evidence is considered valid. The duration must be equal to the time between the starttime and endtime.

Supported Value

Definition

Value for an Information Concept that is provided by an Evidence.

Usage Note

The notion of Supported Value is closely related to actual data exchange between two parties: (a) the Requirement processor, i.e. the Agent setting out Requirements for an objective and processing the supplied Evidences in the context of the Requirements, and (b) the Evidence provider, i.e. the Agent supplying information to an information request expressed as Requirements. The Requirement processor has expressed its expectations (both business as technical) for the information it wants to recieve as an Information Concept. The Evidence provider is able to supply information for that Information Concept, but its native data representation might not be coherent with the expectations set by the Requirement processor. The Supported Value is bridging both. The Evidence provider can either provide a derived value (fact) from its native data representation that complies with the Information Concept expectations. Or it can provide a query in an agreed language between Evidence provider and Requirement processor that allows the Requirement processor to retrieve the value from the native data representation. Implementers are free to choose their language. It is recommended to document the made agreements well.

Properties

For this entity the following properties are defined: provides value for , query , value .

	Property	Range	Card	Definition	Usage
	provides value for	Information Concept	0..*	Information Concept for which the Supported Value provides a value.
	query	Literal	0..*	Search statement that allows the value for the Information Concept to be retrieved from the Evidence data.	The query must be executed on the business data provided by the supporting Evidence. In order to be able to evaluate the query on the provided data, the format of the provided data must be aligned with the query expression. For instance if the provided data is XML, a query in XPath could be expected. This alignment is part of the implementation agreements that implementors must make.
	value	Literal	0..*	Value for the Information Concept that the Evidence supports.

Datatypes

	Class	Definition
	Code	A concept in a codelist.
	Decimal	Decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· of decimal is the set of numbers that can be obtained by dividing an integer by a non-negative power of ten, i.e., expressible as i / 10n wher
	Duration	Duration is a datatype that represents durations of time. The concept of duration being captured is drawn from those of [ISO 8601], specifically durations without fixed endpoints.
	Instant	A temporal entity with zero extent or duration
	Literal	The class of literal values, eg. textual strings and integers.
	String	The string datatype represents character strings in XML.