Is an organisation or a physical person
Body
Represents an n-ary relationship between a Body and a role
Organisation Role
Relates the Organisation role instance (the role played by an Organisation) with the specific role in the taxonomy of organisation roles.
has organisation role
Indicates the relationship of a Body to the organisation roles that it can play.
role
Indicates the corresponding Body that plays a certain organisation role.
role of
A work in a legislative corpus. This applies to acts that have been legally enacted (whether or not they are still in force). For example, the abstract concept of the legal resource; e.g. "act 3 of 2005" (adapted from Akoma Ntoso) A legal resource can represent a legal act or any component of a legal act, like an article. Legal resources can be linked together using properties defined in the model. Note that ELI ontology accommodates different point of view on what should be considered a new legal resource, or a new legal expression of the same resource. Typically, a consolidated version can be viewed, in the context of ELI, either as separate legal resource (linked to original version and previous consolidated version using corresponding ELI relations), or as a different legal expression of the same legal resource.</rdfs:comment>
Legal Resource
member
A temporal entity with an extent or duration
Una entidad temporal con una extensión o duración.
Interval
Time interval
intervalo de tiempo
A temporal interval or instant.
Un intervalo temporal o un instante.
Temporal entity
entidad temporal
European Union Agency for Railways
ERA Ontology for verified permissions
ERA ontology for verified permissions, as applied in vehicle(type) authorisations, registrations and approvals
The Verified Permissions (VP) ontology
Revision 1.1 (13-01-2026, 21-01-2026) - Added a property `vpa:statement` and `vpa:checkResult` to express a statement and a structured result category on a Compliance check. - Provided `vpa:documentsRequest` & `vpa:documentsCase` to allow individual EvidenceDocument's to support a Request or a Case. - Removed `vpa:supportsRequest` from the file (already in Comments) Revision 1.0 (23-05-2025) - Removed sameAs between property vpa:submittedfor - vpa:supportsRequest and added altLabel instead for the naming. - Added `vpa:permits` which allows refining what the `vpa:Permission` actually permits (range: SKOS) - Added `vpa:requestedIn`, as the true inverse of `vpa:requestFor` Revision 0.9 (15-05-2025): - Changed `vpa:supportsRequest` to have domain `vpa:Evidence` (in order to be in line with all other supports properties) - Added `vpa:constitutes` as the true inverse of `vpa:constitutedBy` (change regarding version 0.5). Revision 0.8 (14-05-2025): - Isolated domain of `vpa:checkedCompliance` (renamed from `vpa:checked`) to `vpa:EvidenceDocument` - Keep the link between Evidence and Compliance, using `vpa:statesCompliance` (renamed from `vpa:supportsCompliance` in order to avoid confusion with the supports class). - Added `vpa:supportsScope`, as it is third level of `supports` for vpa:Evidence - Added comments for the supports subProperties - corrected to rdfs:isDefinedBy some links to vpa: - added property `vpa:versionNumber` for `vpa:EvidenceDocument` (a sequence numbering integer) - corrected typo, annotated and commented `vpa:constitutedBy` - added ORCID MD Revision 0.7 (02-04-2025): - renamed supports properties - added subclassOf vpa:Requirement of eli:LegalResource - added a super property for supports-alike properties Revision 0.6 (27-03-2025): - added new properties vpa:supportsRequest, vpa:supportsCase - refined domain and range of classes vpa:Evidence Revision 0.5 (21-02-2025): - Introduction of `vpa:Evidence`, and renaming of `vpa:DocumentedEvidence` to `vpa:EvidenceDocument` - Adding properties: `vpa:constitutes`/ `vpa:constitutedBy`, to link EvidenceDocument with Evidence and inversely; `vpa:checkedRequirement` (`vpa:closes` for `vpa:Compliance`) - Moving some properties from `EvidenceDocument` to `Evidence`. - Improving/adapting the comments of relevant properties.
Accredited organization which is able to express a formal opinion on Requirements, expressing them in EvidenceDocument (mostly called Certificates), and if necessary making them dependent on Restrictions, which shall be fulfilled.
Appropriate Body
A clearly separated part of a Request, identified clearly by its Scope(s). Each Case has an individual PermissionType as objective. A Request consists out of minimally one Case.
Case
Regroups the result of a compliance check on a specific section of an applicable Requirement as registered in Documented Evicence. If needed, links this examined section to a specific Restriction.
Compliance
Evidence
Issued by an AppropriateBody, it is the summary of its formal and accredited verification process, enabling the receiver (RequestingBody) to issue a Request for a Permission to the PermittingBody.
Documented Evidence
Issued by a PermittingBody, it enables - mostly because of legal frameworks in place - the RequestingBody to execute the processes covered under these requirement frameworks.
Permission
Within its legally recognized mandate, this Body is able to receive EvidenceDocument as submitted in a Request and based upon it, issue a Permit to the RequestingBody for the activities covered by the mentioned legislation.
Permitting Body
Issued by a Requesting Body to a PermittingBody, and supported by at least one Case, while being supported by the necessary Evidence (consisting of EvidenceDocuments), it intends to enable the reception of a Permission.
Request
Within its legally recognized role, this Body is able to express the intention to act under the condition of reception of a Permission. The intended action being covered by legal or standardized Requirements to fullfil, this Body will present all required information, as verified by the Appropriate and examined by the Permitting Bodies, to the latter in order to receive the mentioned Permission.
Requesting Body
A legal/standardised collection of rules, which must be verified independently to be met in the context of a Permission Request, and of which the measure of compliance is expressed in EvidenceDocuments, with or without added Restrictions.
Requirement
ERA has the list of TSIs as instances of this class to be released as reference data in RDF
Issued by an Appropriate Body in connection with its (documented) evidence on a certain requirement, it contains all aspects to take into account in order to accept the Evidence as proof, enabling the scope of the Permission. It is possible that the Restriction limits the Permission in the same way.
Restriction
A collection of Scopes together defining a Case. Scope is mostly the specific material object of the Case, where the Case groups them together.
Scope
within its accredited competencies, can express an opinion whether a (legal or standardized) requirement is met. This relation must be accompanied by Evidence(Document) to formalize this opinion and eventually Restrictions if it is met only partially.
certifies
For a Compliance check, a structured expression of the result. Can detail and should be consistent with the boolean result under `isCompliant`.
compliance check result
The Compliance checks having been documented by the Appropriate Body in the EvidenceDocument.
checked compliance
Use `statesCompliance` for the relation Evidence -- Compliance`
For a Compliance check, the Requirement which was (globally or in part) checked by the Appropriate Body.
checked requirement
For a Compliance check, the section of the Requirement which was individually checked by the Appropriate Body. The sections in scope of the verification are registered under each Requirement itself.
checked section
within the accredited competencies of the issuer of the EvidenceDocument, confirms that the evidence shown in the context of the Requirement was (not, partially or fully) fulfilled, where needed in presence of a Restriction.
closes
holds as material content, constitutes, embodies the material components of the Scope.
concerns
holds as a complete, independent, possibly sole part, embodies as one element of potentially more
constituted by
forms a complete, independent, possibly sole part of a request
is part of, inherently constitutes
constitutes
Inverse property of `vpa:concerns`. Is covered by, included in
defines case
within its accredited mandate, issues in a traceable and qualitative manner for reuse in a Permission process
delivers
supporting, as a single provided document, a case, used when a precise case can be linked to this evidence document only
documents case
supporting, as a single provided document, a request, used when no more precise case or exact scope can be linked to this evidence document
documents request
within its legally recognized mandate, issues, delivers in a traceable and qualitative manner, such that the receiver is able to act within the authorisation cases and its verified documentation
grants
For the verified section of a Requirement: true when fully compliant, false in other cases (in which a clarifying Restriction is possible)
is compliant
transmits with the intention to be allowed to act according to a legally verified process
issues
the detailed process which constitutes this Case's permission conditions
permission type
the process, activity, role or other scope which the Permission allows to the Requesting Body to execute or hold
permits
For an ECM Certificate, vpa:permits will link to the OrganisationalRole 'ECM'
belonging to, and when being respected, then also fulfilling
regarding
The linked requirement URI must remain consistent with the Compliance check, if both are used. This property should be used if no trace of a Compliance check is present, apart from the checked Requirement itself.
aiming to be enabled to act as covered by the Permission and its conditions, by receiving
request for
aiming to be enabled to act as covered by the Permission and its conditions, by issuing
requested in
aims to be allowed to act according to a legally verified process, by receiving
requests
section(s) of the requirement to which individual compliance can be registered by the Appropriate Body
sections
Any statement on the Compliance, like e.g. those typically filled in on checklists, annexed to the Permission
compliance statement
stating, through a collective set of evidence providing documents, a (non)compliance, instantiated as a `vpa:Compliance`
states compliance
the status of the Request as it is being treated by the PermittingBody
status
supporting, holding evidence of compliance in order to enable the Permitting Body to verify and permit
submitted for
supports Request
Replaces the removed `vpa:supportsRequest`-predicate
The submission of a permission or evidence to a case
submitted in
super property for the different targets of supporting evidence: the scope, a case or the full request
supports
supporting, as a collective set of evidence providing documents, a specific case, as such also supporting the request
supports case
supporting, as a collective set of evidence providing documents, a specific, material scope within a case, as such also supporting the request
supports scope
valid during a certain time
valid
The validity of Evidence should be based on the validity limits of the EvidenceDocuments it is constitutedBy. The validity of a Permission (checked e.g. with SHACL) should also be consistent with the validity of the underlying Evidence.
An integer representing any sequence number of a version of an EvidenceDocument. Subsequent EvidenceDocuments SHOULD use `dcterms:isReplacedBy` and `dcterms:replaces` to indicate their relation.
version number
when taken into account in the final act to be permitted, can be accepted if the conditions of the Restriction are fully answered to
with restriction
Only Compliance checks and specific EvidenceDocuments are precise enough to form the basis of a Restriction. Therefore, Evidence itself cannot directly link to a Restriction