Core Criterion and Core Evidence Vocabulary

Summary

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.

Using these basic core concepts, CCCEV provides a generic setting to define Criteria, i.e. Requirements with an assessment or evaluation objective in mind. This is a key motivation for the existence of CCCEV.

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.

An explanatory example that helps the reader to better understand this specification can be found here.

Status of this document

This Core Vocabulary has the status of Semic Recommendation published at 2022-01-20.

Overview

Entities

Agent

Definition: Entity that is able to carry out action.
Usage: In compliance with the description from FOAF, an Agent is considered as any entity that is able to carry out actions. The Agent class acts as a generic element which can be further specified by implementers for their usages, for example by defining the Person class from the Core Person Vocabulary or Organization from W3C's Organization Ontology as subclasses of Agent. This Person or Organization can then issue a certain Requirement or be concerned by an Evidence provided.
Properties: No properties have been defined for this entity in the scope of this specification.

Constraint

Definition: Limitation applied to an Information Concept.
Usage: 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	Expected Range	Definition	Usage	Codelist
`constrains`	Information Concept	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: 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	Expected Range	Definition	Usage
`bias`	Decimal	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	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	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	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 Number weight. An example of its use is shown here

Dataset

Definition: Collection of data.
Usage: In v2.0.0, CCCEV relies on DCAT, a vocabulary for cataloging datasets and services, to share metadata about an Evidence. This dependence is made explicit by subclassing Evidence from dcat:Dataset. This is justified by the fact that a lot of the information needed for describing Evidences is described in DCAT, such as the issue date, creator, title, etc. Furthermore, other useful parts from DCAT can be reused, such as the Distribution class.
Properties: For this entity the following properties are defined: identifier.

Property	Expected Range	Definition	Usage	Codelist
`identifier`	Literal	Unambiguous reference to the Dataset.

Evidence

Definition: Proof that a Requirement is met.
Usage: 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.
Subclass of
: Dataset
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	Expected Range	Definition	Usage
`confidentiality level type`	Code	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	Agent that is the subject in the provided Evidence.
`is conformant to`	Evidence Type	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	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	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	Agent that transmits the Evidence.	Agents transmitting Evidence are usually the Agents requesting the Evidence or service providers acting on behalf of the requesting Agents such as software developer companies.
`supports concept`	Information Concept	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	Requirement for which the Evidence provides proof.
`supports value`	Supported Value	Supported Value that the Evidence contains.
`validity period`	Period of Time	Period of Time during which the Evidence holds true or has force.

Evidence Type

Definition: Information about the characteristics of an Evidence.
Usage: 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	Expected Range	Definition	Usage
`evidence type classification`	Code	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	Unambiguous reference to the Evidence Type.
`is specified in`	Evidence Type List	Evidence Type List in which the Evidence Type is included.
`issuing place`	Location	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	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: 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	Expected Range	Definition	Usage
`description`	String	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	Unambiguous reference to the Evidence Type List.
`name`	String	Name of the Evidence Type List.
`specifies evidence type`	Evidence Type	Evidence Type included in this Evidence Type List.

Information Concept

Definition: Piece of information that the Evidence provides or the Requirement needs.
Usage: 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	Expected Range	Definition	Usage
`description`	String	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	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	Unambiguous reference to the Information Concept.
`name`	String	Name of the Information Concept.
`type`	Code	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 types 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.

Information Requirement

Definition: Requested data that is to be proven by Evidence.
Usage: Information Requirements are the most neutral kind of Requirements. They aim to request information in any form, e.g. a person's date of birth or a company's turnover. They represent requests for data that prove one or more facts of the real world in a formal manner, or that leads to the source of such a proof. They can be understood as 'requests for Evidences'. The response to an Information Requirement is an Evidence when the issuer of the response is an authoritative source (e.g. a Civil Registry providing data about a natural person for the provision of public service through the Single Digital Gateway). In other cases, the responses might not be issued by an authoritative source, but the issuer supports the responses with Evidences (or commits to support them timely, e.g. a self-declaration or a declaration of oath). The Information Requirement can require structured data or documents of any form. For structured data, the Requirement can use 'Concepts' to specify the structure and type of the data expected in the response. For both structured and unstructured data, the Information Requirement can indicate the expected Type of Evidence, its format, source, and other properties related to the Evidence.
Subclass of
: Requirement
Properties: No properties have been defined for this entity in the scope of this specification.

Location

Definition: Identifiable geographic place or named place.
Properties: No properties have been defined for this entity in the scope of this specification.

Period of Time

Definition: A temporal entity with non-zero extent or duration.
Usage: 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	Expected Range	Definition	Usage
`duration`	Duration	Extent of the Period of Time.	Amount of time between start time and end time.
`endtime`	DateTime	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`	DateTime	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.

Reference Framework

Definition: Legislation or official policy from which Requirements are derived.
Usage: 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	Expected Range	Definition	Usage	Codelist
`identifier`	Literal	An unambiguous reference to a Reference Framework.

Requirement

Definition: Condition or prerequisite that is to be proven by Evidence.
Usage: 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.
To illustrate the notion: 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	Expected Range	Definition	Usage
`description`	String	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	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	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	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	A more specific Requirement that is part of the Requirement.
`has supporting evidence`	Evidence	Evidence that supplies information, proof or support for the Requirement.
`identifier`	Literal	Unambiguous reference to a Requirement.
`is derived from`	Reference Framework	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	Agent that has published the Requirement.
`is requirement of`	Requirement	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	Name of the Requirement.
`type`	Code	Category to which the Requirement belongs.

Supported Value

Definition: Value for an Information Concept that is provided by an Evidence.
Usage: 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	Expected Range	Definition	Usage
`provides value for`	Information Concept	Information Concept for which the Supported Value provides a value.
`query`	Literal	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	Value for the Information Concept that the Evidence supports.

Implementation note

(non-normative)

CCCEV as a Core Vocabulary is implementation-neutral. CCCEV does not impose any choices regarding how the data is being exchanged. Furthermore, CCCEV does not enforce the information carried in an Evidence to be directly accessible i.e. contained within the payload of the response. However, CCCEV does offer several ways to implement these aspects: (1) via subclassing of the Evidence class, (2) via sharing it as a dcat:Distribution or (3) via the class Supported Value. These are three distinguishable approaches, which can be used independently from each other, or in combination.

CCCEV provides a framework for the implementers to define the actual information models and metadata models an Evidence should comply to. For example, a Birth Certificate model could be defined as a particular Evidence Type to which the Evidence shared by the competent authority should conform to. This information model would make use of existing metadata models. The implementer can define one or several domain specific models for defining the information acceptable or required within an Evidence.

In practice, an Evidence (from the perspective of being a document) often provides more information than is required for the decision making process. Despite that it might be possible to express all these information pieces as Information Concepts, this remains a choice for the implementer. It is not the intent of CCCEV to provide a full-fledged data modeling framework with the notion of Information Concept and Supported Value. Usages such as creating Information Concepts independent from Requirements or providing Values for Information Concepts that are not requested by a Requirement should be considered as unintended usages, beyond the scope of CCCEV.

Changelog w.r.t. latest version

(non-normative)

A changelog describing the (major) changes to the previous version (1.0.0) of the Core Criterion and Core Evidence Vocabulary (released in December 2016) and the new version that is here being proposed (2.0.0), can be found here.

UML representation

(non-normative)

The UML representation from which this Core Vocabulary has been build is available here.

RDF representation

(non-normative)

A reusable RDF representation (in turtle) for this Core Vocabulary is retrievable here.
This RDF file contains only the terminology for which the URI is minted in the Core Vocabularies domain http://data.europa.eu/m8g. Terms that are mapped on an existing URI (hence reused from other vocabularies) are not included.

JSON-LD context

(non-normative)

A reusable JSON-LD context definition for this Core Vocabulary is retrievable here.

SHACL template

(non-normative)

A reusable SHACL template for this Core Vocabulary is retrievable here.