@prefix dc: .
@prefix foaf: .
@prefix owl: .
@prefix rdf: .
@prefix rdfs: .
@prefix schemas: .
@prefix skos: .
@prefix xsd: .
a owl:Class;
rdfs:label "Information Requirement"@en;
rdfs:comment "Requested data that is to be proven by Evidence."@en;
rdfs:isDefinedBy ;
rdfs:subClassOf ;
skos:scopeNote "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."@en .
a owl:DatatypeProperty;
rdfs:label "bias"@en;
rdfs:comment "Parameter used to adjust the evaluation of the Criterion."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range xsd:decimal;
skos:scopeNote "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."@en .
a owl:ObjectProperty;
rdfs:label "confidentiality level type"@en;
rdfs:comment "Security classification assigned to an Evidence e.g. classified, sensitive, public."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range skos:Concept;
skos:scopeNote "Classifications should be defined by an organisation/country as an outcome of a security assessment."@en .
a owl:ObjectProperty;
rdfs:label "constrains"@en;
rdfs:comment "Information Concept about which a Constraint expresses a limitation."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "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."@en .
a owl:ObjectProperty;
rdfs:label "evidence type classification"@en;
rdfs:comment "Category to which the Evidence Type belongs."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range skos:Concept;
skos:scopeNote "The categories agreed are left open but could for example specify the layout and content expected for an Evidence."@en .
a owl:DatatypeProperty;
rdfs:label "expression of expected value"@en;
rdfs:comment "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 ."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range rdfs:Literal;
skos:scopeNote """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 boundary 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).
"""@en .
a owl:ObjectProperty;
rdfs:label "has concept"@en;
rdfs:comment "Information Concept for which a value is expected by the Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "Information Concepts defined for specific Requirements also represent the basis for specifying the Supported Value an Evidence should provide."@en .
a owl:ObjectProperty;
rdfs:label "has evidence type list"@en;
rdfs:comment "Evidence Type List that specifies the Evidence Types that are needed to meet the Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "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."@en .
a owl:ObjectProperty;
rdfs:label "has qualified relation"@en;
rdfs:comment "Described and/or categorised relation to another Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "This property leaves the possibility 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."@en .
a owl:ObjectProperty;
rdfs:label "has requirement"@en;
rdfs:comment "A more specific Requirement that is part of the Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "has supporting evidence"@en;
rdfs:comment "Evidence that supplies information, proof or support for the Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "is derived from"@en;
rdfs:comment "Reference Framework on which the Requirement is based, such as a law or regulation."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "Note that a Requirement can have several Reference Frameworks from which it is derived."@en .
a owl:ObjectProperty;
rdfs:label "is requirement of"@en;
rdfs:comment "A reference between a sub-Requirement and its parent Requirement."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote """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."""@en .
a owl:ObjectProperty;
rdfs:label "is specified in"@en;
rdfs:comment "Evidence Type List in which the Evidence Type is included."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "provides value for"@en;
rdfs:comment "Information Concept for which the Supported Value provides a value."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:DatatypeProperty;
rdfs:label "query"@en;
rdfs:comment "Search statement that allows the value for the Information Concept to be retrieved from the Evidence data."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range rdfs:Literal;
skos:scopeNote "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."@en .
a owl:ObjectProperty;
rdfs:label "specifies evidence type"@en;
rdfs:comment "Evidence Type included in this Evidence Type List."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "supports concept"@en;
rdfs:comment "Information Concept providing facts found/inferred from the Evidence."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "Examples of Information Concepts are values found explicitly in the evidence such as a birth date or information derived from the Evidence such as \"I am older that 18 years\"."@en .
a owl:ObjectProperty;
rdfs:label "supports requirement"@en;
rdfs:comment "Requirement for which the Evidence provides proof."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "supports value"@en;
rdfs:comment "Supported Value that the Evidence contains."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "validity period"@en;
rdfs:comment "Period of Time during which the Evidence holds true or has force."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range .
a owl:ObjectProperty;
rdfs:label "validity period constraint"@en;
rdfs:comment "Temporal condition on the validity period of the Evidence Type."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range ;
skos:scopeNote "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."@en .
a owl:DatatypeProperty;
rdfs:label "value"@en;
rdfs:comment "Value for the Information Concept that the Evidence supports."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range rdfs:Literal .
a owl:DatatypeProperty;
rdfs:label "weight"@en;
rdfs:comment "Relative importance of the Criterion."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range xsd:decimal;
skos:scopeNote "The weight must be between 0 and 1. Usually, all Criteria can be integrated within a weighted sum equal to 1."@en .
a owl:DatatypeProperty;
rdfs:label "weighting consideration description"@en;
rdfs:comment "Explanation of how the weighting of a Criterion is to be used."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range xsd:string;
skos:scopeNote "This description gives the view of the creator of the Criterion weights on how to interpret and use them during the evaluation process."@en .
a owl:ObjectProperty;
rdfs:label "weighting type"@en;
rdfs:comment "Indication of how the weight should be interpreted in a complex evaluation expression, e.g. as a percentage in an evaluation expression."@en;
rdfs:domain ;
rdfs:isDefinedBy ;
rdfs:range skos:Concept;
skos:scopeNote "An existing codelist which can be used is OP's Number weight controlled vocabulary"@en .
a owl:Class;
rdfs:label "Constraint"@en;
rdfs:comment "Limitation applied to an Information Concept."@en;
rdfs:isDefinedBy ;
rdfs:subClassOf ;
skos:scopeNote "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."@en .
a owl:Class;
rdfs:label "Reference Framework"@en;
rdfs:comment "Legislation or official policy from which Requirements are derived."@en;
rdfs:isDefinedBy ;
skos:scopeNote "Usual Reference Frameworks are legal and non-legal specifications. Examples include procedures, tendering legislation, etc."@en .
a owl:Class;
rdfs:label "Evidence Type List"@en;
rdfs:comment "Group of Evidence Types for conforming to a Requirement."@en;
rdfs:isDefinedBy ;
skos:scopeNote """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."""@en .
a owl:Class;
rdfs:label "Criterion"@en;
rdfs:comment "Condition for evaluation or assessment."@en;
rdfs:isDefinedBy ;
rdfs:subClassOf ;
skos:scopeNote """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."""@en .
a owl:Class;
rdfs:label "Evidence Type"@en;
rdfs:comment "Information about the characteristics of an Evidence."@en;
rdfs:isDefinedBy ;
skos:scopeNote "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)."@en .
a owl:Class;
rdfs:label "Supported Value"@en;
rdfs:comment "Value for an Information Concept that is provided by an Evidence."@en;
rdfs:isDefinedBy ;
skos:scopeNote """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 receive 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.
"""@en .
a owl:Class;
rdfs:label "Information Concept"@en;
rdfs:comment "Piece of information that the Evidence provides or the Requirement needs."@en;
rdfs:isDefinedBy ;
skos:scopeNote "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."@en .
a owl:Class;
rdfs:label "Evidence"@en;
rdfs:comment "Proof that a Requirement is met."@en;
rdfs:isDefinedBy ;
skos:scopeNote """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."""@en .
a owl:Class;
rdfs:label "Requirement"@en;
rdfs:comment "Condition or prerequisite that is to be proven by Evidence."@en;
rdfs:isDefinedBy ;
skos:scopeNote "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."@en .
a owl:Ontology;
rdfs:label "cccev"@en,
"cccev"@nl;
dc:issued "2026-05-12";
dc:license ;
dc:mediator [
foaf:homepage ;
foaf:name "Semantic Interoperability Community (SEMIC)"
];
[
a foaf:Person;
foaf:firstName "Jitse";
foaf:lastName "De Cock";
schemas:affiliation [foaf:name "PwC EU Services"]
], [
a foaf:Person;
foaf:firstName "Emiel";
foaf:lastName "Dhondt";
schemas:affiliation [foaf:name "Digital Flanders"]
], [
a foaf:Person;
foaf:firstName "Faruk";
foaf:lastName "Karabulut";
schemas:affiliation [foaf:name "PwC EU Services"]
], [
a foaf:Person;
foaf:firstName "Anastasia";
foaf:lastName "Sofou";
schemas:affiliation [foaf:name "European Commission"]
], [
a foaf:Person;
foaf:firstName "Emidio";
foaf:lastName "Stani";
schemas:affiliation [foaf:name "PwC EU Services"]
], [
a foaf:Person;
foaf:firstName "Bert";
foaf:lastName "Van Nuffelen";
schemas:affiliation [foaf:name "Digital Flanders"]
];
foaf:maker [
a foaf:Person;
foaf:firstName "Core Vocabularies Working Group"
] .