Proof Of Disability Of Sibling

Abstract

Proof of disability is a simplified data model describing a request for evidence proving the status "person with disability" for a person's (evidence subject) sibling.

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.

Prefix	Namespace IRI
`cv`	`http://data.europa.eu/m8g/`
`dct`	`http://purl.org/dc/terms/`
`foaf`	`http://xmlns.com/foaf/0.1/`
`locn`	`http://www.w3.org/ns/locn#`
`oots`	`http://data.europa.eu/p4s/`
`person`	`http://www.w3.org/ns/person#/`
`rdf`	`http://www.w3.org/1999/02/22-rdf-syntax-ns#`
`rdfs`	`http://www.w3.org/2000/01/rdf-schema#`
`skos`	`http://www.w3.org/2004/02/skos/core#`

	Property	Range	Card	Definition	Usage
	is about	Person	1	Agent that is the subject in the provided Evidence.
	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
date of expiry of disability status	GenericDate	0..*	The point in time on which the proof of disability ends.
date of issue of disability status	GenericDate	0..*	The point in time on which the Person has acquired its disability.
disability degree	Code	0..*	Extent or magnitude of impairment.
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: date of birth , family name , given name , has sibling .

Property	Range	Card	Definition	Usage
date of birth	GenericDate	0..*	The point in time on which the Person was born.	The date of birth could be expressed as date, gYearMonth or gYear, example: 1980-09-16^^xs:date 1980-09^^xs:gYearMonth 1980^^xs:gYear
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".
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".
has sibling	Person	0..*	A person that has a parent in common.

	Class	Definition
	Code	An idea or notion; a unit of thought.
	GenericDate	The date data type is the union of xs:date, xs:gYearMonth and xs:gYear.
	Text	The text data type is a combination of a string and a language identifier.

Examples

No examples defined

Usage Guidelines

Support for implementation

The following section provides support for implementing the Proof Of Disability Of Sibling.

JSON-LD context file

One common technical question is the format in which the data is being exchanged. For conformance with the Proof Of Disability Of Sibling, it is not mandatory that this happens in a RDF serialisation, but the exhanged format SHOULD be unambiguously be transformable into RDF. For the format JSON, a popular format to exchange data between systems, SEMIC provides a JSON-LD context file. JSON-LD is a W3C Recommendation [[[json-ld11]]] that provided a standard approach to interpret JSON structures as RDF. The provided JSON-LD context file can be used by implementers. This JSON-LD context is not normative, i.e. other JSON-LD contexts are allowed.

The JSON-LD context file downloadable here.

Validation

To verify if the data is (technically) conformant to the Proof Of Disability Of Sibling, the exchanged data can be validated using the provided SHACL shapes. SHACL is a W3C Recommendation to express constraints on a RDF knowledge graph.

To support the check whether or not a catalogue satisfies the expressed constraints in this Application Profile, the constraints in this specification are expressed using SHACL [[shacl]]. Each constraint in this specification that could be converted into a SHACL expression has been included. As such this collection of SHACL expressions that can be used to build a validation check for data.

It is up to the implementers to define the validation they expect. Each implementation happens within a context, and that context is beyond the SHACL expressions here.

The shapes can be found here.

RDF representation

The RDF representation of the Proof Of Disability Of Sibling is available here.

UML representation

The UML representation from which the Proof Of Disability Of Sibling has been build is available here.

No XML schema defined

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:

a dct:isReplacedBy referencing the new assets used instead and
an adms:status indicating its deprecated status.

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:

The asset is part of a recommendation by a major standards body or an EU institution.
The asset is actively being maintained.

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

Syntax validation will be performed on the relevant artefacts.
Constraint validation will be performed on the relevant artefacts.
The PURI will be validated.

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:

rdfs:label is used to provide a human-readable version of a resource's name.
The usage of certain resource can be clarified in a skos:usageNote.

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.

Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.
Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.
Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.
Deprecated property: a receiver SHOULD be able to process information about instances of that property; a sender SHOULD NOT provide the information about instances of that property.

Class	Class IRI	Property	Property IRI
Disability	http://data.europa.eu/p4s/Disability	date of expiry of disability status	http://data.europa.eu/p4s/dateOfExipryOfDisabilityStatus
Disability	http://data.europa.eu/p4s/Disability	date of issue of disability status	http://data.europa.eu/p4s/dateOfIssueOfDisabilityStatus
Disability	http://data.europa.eu/p4s/Disability	disability degree	http://data.europa.eu/p4s/disabilityDegree
Disability	http://data.europa.eu/p4s/Disability	type of disability	http://data.europa.eu/p4s/typeOfDisability
Evidence Type	http://data.europa.eu/m8g/EvidenceType
Person	http://www.w3.org/ns/person#Person	date of birth	http://data.europa.eu/m8g/birthDate
Person	http://www.w3.org/ns/person#Person	family name	http://xmlns.com/foaf/0.1/familyName
Person	http://www.w3.org/ns/person#Person	given name	http://xmlns.com/foaf/0.1/givenName
Person	http://www.w3.org/ns/person#Person	has sibling	http://data.europa.eu/p4s/hasSibling
Proof of disability of sibling	http://data.europa.eu/p4s/ProofOfDisabilityOfSibling	is about	http://purl.org/dc/terms/subject
Proof of disability of sibling	http://data.europa.eu/p4s/ProofOfDisabilityOfSibling	states	http://data.europa.eu/p4s/states

Abstract

Introduction

Status

License

Terminology

Overview

Main Entities