SEMIC

Core Criterion and Core Evidence Vocabulary

Status
Working Draft
Published at
2021-03-08
This version
https://semiceu.github.io/CCCEV/releases/2.00

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, implementations 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 of this document

This Core Vocabulary has the status of Working Draft published at 2021-03-08.

Conformance

TBD

Overview

This document describes the usage of the following entities for a correct usage of the Core Vocabulary:
| Agent | Constraint | Criterion | Dataset | Evidence | Evidence Type | Evidence Type List | Information Concept | Information Requirement | Reference Framework | Requirement | Supported Value |

Entities

Agent

Description
Any entity that is able to carry out actions.
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.

Constraint

Description
A limitation applied to Requirement(s) or to the Information Concept(s) the Requirement is about.
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 Description Usage Codelist
constrains Information Concept The 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

Description
A 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. 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 Description Usage Codelist
bias Decimal Additional parameter(s) used to adjust the evaluation of the Criterion composed of multiple sub-Criteria and their respective weights. In neural networks, the bias is equivalent to an intercept added in a linear equation used to shift the activation function to either right or left. It can be also used to manually adjust the pass/fail calculation of a weighted criterion.
weight Decimal Relative importance assigned to a given Criterion.
weighting consideration description String The explanation of how the weighting of a Criterion is to be used at evaluation time.
weighting type Code The numeric form used to weight.

Dataset

Description
A collection of data.
Usage
To share metadata about an Evidence, CCCEV relies on DCAT, a vocabulary for cataloging datasets and services. 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, distribution, etc.
Properties
No properties have been defined for this entity.

Evidence

Description
The data proving that a Requirement is met or has been fulfilled.
Usage
The term data used in the definition of Evidence must be understood in its broadest sense as any type of data, independently from its structure, format or medium used to exchange it: a pdf document, a video, a recording, etc. are all considered as data. The class Evidence provides the means to support responses to Criteria or to a concrete Information Requirement or to a granular Information Concept inside an Information Requirement.
Subclass of
Dataset
Properties
For this entity the following properties are defined: confidentiality level type, is about, is conformant to, supports concept, supports requirement, supports value.
Property Expected Range Description Usage Codelist
confidentiality level type Code The security classification assigned to an Evidence or, in general, to a content.
is about Agent The Agent that is the main actor in the provided Evidence.
is conformant to Evidence Type A reference to one or more types of Evidence where the content and, possibly, the layout or configuration of the Evidence is specified. This property can be fulfilled with the dcat property dct:conformsTo. The definition should reflect the need for another property and the usage note should make the distinction clear.
supports concept Information Concept The Information Concept that is supported by the Evidence. Used to express details about the information that is provided by the Evidence.
supports requirement Requirement The Requirement for which the Evidence provides information (proof, support).
supports value Supported Value The Supported Value for which an Evidence holds information.

Evidence Type

Description
Information about the characteristics of an expected Evidence.
Usage
Examples of Evidence Types include birth certificates, marriage evidences, university diploma's, etc. These are not concrete individual responses to a Requirement (Evidences), but descriptions about the desired form, content, source and/or other characteristics that an actual response should have and provide. For a specific Requirement, the requester can define the List of Evidence Types which would be accepted and, for each Evidence Type in this list, the specific information and form that should be part of the Evidence actually provided in order to answer the Requirement. Evidence Types can express conditions for an acceptable response at two levels: the concrete information that is being requested, and the metadata about how this concrete information is being obtained. This way, the Evidence Type can capture specific characteristics such as a specific format or source of the Evidence, as such characteristics may be strictly required depending on the Requirement. Implementations are free, however, to set the level of detail (i.e. number of characteristics) they want to specify for Evidence Types.
Properties
For this entity the following properties are defined: evidence type classification, is specified in.
Property Expected Range Description Usage Codelist
evidence type classification Code A classification code to specify the layout and content expected for an Evidence. This classification could be used for example for providing a common list of Evidence Types accepted within a specific domain.
is specified in Evidence Type List Refers to an Evidence Type List in which the Evidence Type is included.

Evidence Type List

Description
A combination of Evidence Types for each of which a conforming Evidence must be provided.
Usage
An Evidence Type List is satisfied if and only if for all included Evidence Types a corresponding conformant Evidence is 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 Description Usage Codelist
description String A short explanation about the nature, attributes, uses or any other additional information that helps clarify the understanding of the Evidence Type being instantiated.
identifier Literal An unambiguous reference to an Evidence Type List.
name String The name of the Evidence Type List.
specifies evidence type Evidence Type Indicates one Type of Evidence included in a List of Evidence Types.

Information Concept

Description
A reference to an entity, i.e. a class or a property, which is used to describe information in the Evidence to be provided for the Requirement specified.
Usage
An Information Concept is a piece of information that the Evidence provides in the context of a Requirement (or from the perspective of a Requirement: a piece of information that a Requirement needs), e.g. a person's age. The CCCEV modeling of Information Concepts and Supported Values exists, however, to provide a machine-processable way to connect information that an Evidence provides with the information a Requirement requires to make a decision.
Properties
For this entity the following properties are defined: description, identifier, name, type.
Property Expected Range Description Usage Codelist
description String A short explanation about the nature, attributes, uses or any other additional information that helps clarify the understanding of the Information Concept being instantiated.
identifier Literal An unambiguous reference to the Information Concept.
name String A name of the Information Concept.
type Code A classification of the Information Concept.

Information Requirement

Description
A request for data that is proof of Evidence or that leads to the source of such a proof.
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 proves 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.

Reference Framework

Description
A source from where Requirements are identified and derived.
Usage
Usual Reference Frameworks are legal and non-legal specifications. Examples include procedures, tendering legislation, etc.
Properties
No properties have been defined for this entity.

Requirement

Description
A condition or prerequisite that someone requests and someone else has to meet.
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 semanticall-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.
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 requirement of, issued by, name, type.
Property Expected Range Description Usage Codelist
description String A short explanation about the nature, attributes, uses or any other additional information that helps clarify the understanding of the Requirement being instantiated.
has concept Information Concept The Information Concept for which the Requirement expects a support in the supporting Evidence. Information Concepts are tools to make Requirements more machine processable: they allow the user to provide more detail about a Requirement. Information Requirements are a request for information. Instead of writing this expectation down as a textual description, associating an Information Concept with the Information Requirement makes the expectation more formal.
has evidence type list Evidence Type List The single or various combinations of Evidence Types for supporting a Requirement. Out of the different Lists, one of them must be satisfied by the response to the Requirement. Often a single kind of response is sufficient, but in many cases different responses can be accepted. For instance, to prove one's identity, a bankcard, social security token, driving license or ID card could be accepted as Evidence. To satisfy this combination, one of the Evidence Type Lists, each containing one of the examples above, must be satisfied: this is thus an OR condition.
has qualified relation Requirement A described and/or categorised relation to the instance of another Requirement class or subclass.
has requirement Requirement A sub-Requirement.
has supporting evidence Evidence The Evidence that supplies information (proof, support) for this Requirement.
identifier Literal An unambiguous reference to a Requirement.
is derived from Reference Framework The Reference Framework that is responsible for the creation/initiation of the Requirement.
is requirement of Requirement A reference between a sub-Requirement and its parent, more general, Requirement. Inverse relation from hasRequirement. If there is no hierarchy then this relationship is not needed.
issued by Agent The Agent that has issued the Requirement.
name String A name to identify in common language the Requirement.
type Code The category or type to which the requirement belongs.

Supported Value

Description
A value for an Information Concept that is supported 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. Obtaining the actual Value for an Information Concept carried by an Evidence is the result of an information retrieval process on the business information of the Evidence. This process can be executed by the Evidence provider. In that case the Evidence provider can supply the Value as is. But it can also be executed by the Requirement processor. If the Requirement processor can process the business information of the supplied Evidence then the Requirement processor can query for the information itself. In CCCEV, the latter case is supported by the query attribute for a Supported Value. So instead of providing a Value, a query on the data is supplied. As described in the Evidence class, CCCEV does not impose how the actual information contained in an Evidence must be exchanged and processed in order to fulfill a Requirement. The combination of Supported Value and Information Concept, is one of the approaches that CCCEV supports.
Properties
For this entity the following properties are defined: provides value for, query, value.
Property Expected Range Description Usage Codelist
provides value for Information Concept The Information Concept for which the Supported Value is providing a value.
query Literal The query via which the value for the Information Concept can be retrieved. The query must be executed on the business data provided by the supporting Evidence.
value Literal The value for the Information Concept that the Evidence is supporting.

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.