Proof of disability

Abstract

Proof of disability is a simplified data model describing a request for evidence regarding the disability of a person (evidence subject). This data model draws upon the birth public document description of REGULATION (EU) 2016/119.

Introduction

The Proof of disability data model provides a minimum set of classes and properties for describing a proof of disability evidence. This data model has been designed to support the different requirements of the OOTS action. The different classes and properties defined in this document are based on the OOTS data dictionary.

Status

This Application Profile has the status Draft published at 2024-08-29.

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

An Application Profile (AP) is a specification that reuses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.

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.

This specification uses the following prefixes to shorten the URIs for readibility.
PrefixNamespace IRI
cvhttp://data.europa.eu/m8g/
dcthttp://purl.org/dc/terms/
foafhttp://xmlns.com/foaf/0.1/
locnhttp://www.w3.org/ns/locn#
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfshttp://www.w3.org/2000/01/rdf-schema#
skoshttp://www.w3.org/2004/02/skos/core#

Overview

This document describes the usage of the following main entities for a correct usage of the Application Profile:
| Proof of disability |

The main entities are supported by:
| Disability | Evidence Type | Person |

And supported by these datatypes:
| Code | GenericDate | Text |

Main Entities

The main entities are those that form the core of the Application Profile.

Proof of disability

Definition
Request for evidence proving that the person (evidence subject) is a person with disability.
Subclass of
Evidence Type
Properties
For this entity the following properties are defined: isAbout , states .
Property Range Card Definition Usage
[o] isAbout Person 1 Agent that is the subject in the provided Evidence.
[o] states Disability 0..* Disability that is stated by the certificate

Supportive Entities

The supportive entities are supporting the main entities in the Application Profile. They are included in the Application Profile because they form the range of properties.

Disability

Definition
Disability is the experience of any condition that makes it more difficult for a person to do certain activities or have equitable access within a given society. Disabilities may be cognitive, developmental, intellectual, mental, physical, sensory, or a combination of multiple factors.
Properties
For this entity the following properties are defined: date of expiry of disability status , date of issue of disability status , disability degree , type of disability .
Property Range Card Definition Usage
[o] date of expiry of disability status GenericDate 0..* The point in time on which the proof of disability ends.
[o] date of issue of disability status GenericDate 0..* The point in time on which the Person has acquired its disability.
[o] disability degree Code 0..* Extent or magnitude of impairment.
[o] type of disability Code 0..* The impairment type of a Person, e.g. aural, skeletal, ocular, mobility, intellectual...

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
This specification does not impose any additional requirements to properties for this entity.

Person

Definition
A individual human being who may be dead or alive, but not imaginary.
Usage Note
The fact that a person in the context of Core Person Vocabulary cannot be imaginary makes person:Person a subclass of foaf:Person which cover imaginary characters as well as real people. The Person Class is a subclass of the more general 'Agent' class.
Properties
For this entity the following properties are defined: family name , given name .
Property Range Card Definition Usage
[o] family name Text 0..* The hereditary surname of a family. Usually referring to a group of people related by blood, marriage or adoption. This attribute also carries prefixes or suffixes which are part of the family name, e.g. "de Boer", "van de Putte", "von und zu Orlow". Multiple family names, such as are commonly found in Hispanic countries, are recorded in the single family name property so that, for example, Miguel de Cervantes Saavedra's family name would be recorded as "de Cervantes Saavedra".
[o] given name Text 0..* The name(s) that identify the Person within a family with a common surname. Usually a first name or forename. Given to a person by his or her parents at birth or legally recognised as 'given names' through a formal process. All given names are ordered in one property so that, for example, the given name for Johann Sebastian Bach is "Johann Sebastian".

Datatypes

The following datatypes are used within this specification.
Class Definition
(create issue) An idea or notion; a unit of thought.
(create issue) The date data type is the union of xs:date, xs:gYearMonth and xs:gYear
(create issue) The text data type is a combination of a string and a language identifier.

Examples

No examples defined

Usage Guidelines

Governance

Versioning governance

All specifications produced in SEMIC will follow the versioning rule described by the SEMIC Style Guide rule PC-R3. In case a SEMIC asset is deprecated the asset will remain available through its PURI.

The serialisation will have:

Governance requirements for re-used assets

In order to adhere to the SEMIC Style Guide rule GC-R2 a specification should have quality and governance standards for the assets that are being reused.

In order for an asset to be considered for reuse within a SEMIC specification it can be requested by a community member or it requires to adhere to the following requirements:

After being taken into consideration the asset will be validated in three steps:

Once considered and validated an asset can be adopted if it is approved by the community.

Lexicalisation rules

In order to adhere to the SEMIC Style Guide rule SC-R3 a specification requires formal lexicalisation rules. The Style Guide proposes two options either by using RDFS or SKOS lexicalisation.

SEMIC uses and will use the RDFS lexicalisation for all of its specifications. More specifically:

Quick Reference of Classes and Properties

This section provides a condensed tabular overview of the mentioned classes and properties in this specification. The properties are indicated as mandatory, recommended, optional and deprecated. These terms have the following meaning.
ClassClass IRIProperty TypePropertyProperty IRI
Disability
oots:Disability
date of expiry of disability status
oots:dateOfExipryOfDisabilityStatus
Disability
oots:Disability
date of issue of disability status
oots:dateOfIssueOfDisabilityStatus
Disability
oots:Disability
disability degree
oots:disabilityDegree
Disability
oots:Disability
type of disability
oots:typeOfDisability
Evidence Type
cv:EvidenceType
Person
person:Person
family name
foaf:familyName
Person
person:Person
given name
foaf:givenName
Proof of disability
oots:ProofOfDisability
isAbout
dct:subject
Proof of disability
oots:ProofOfDisability
states
oots:states

Feedback

Please provide feedback on the discussion forum