Evidence Of Birth

Abstract

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

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#`
`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#`
`sdg`	`http://data.europa.eu/p4s/`
`skos`	`http://www.w3.org/2004/02/skos/core#`

	Property	Range	Card	Definition	Usage
	has birth	Birth	1	Birth event that is the object in the provided Evidence.
	is about	Person	1	Agent that is the subject in the provided Evidence.

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.

Attribute

Definition: The optional property that provides additional descriptive information about a concept.
Properties: This specification does not impose any additional requirements to properties for this entity.

Attribute Set

Definition: The collection of attributes grouped to provide additional descriptive information about a concept.
Properties: For this entity the following properties are defined: has attribute .

	Property	Range	Card	Definition	Usage
	has attribute	Attribute	1..*	The optional property that provides additional descriptive information.

Birth

Definition: Birth event marking an individual's coming into existence.
Properties: For this entity the following properties are defined: country of birth , date of birth , has attribute set , place of birth .

Property	Range	Card	Definition	Usage
country of birth	Location	0..1	The country in which the Person was born.	The Location Class has two properties: a Geographic Name and a Geographic Identifier. Plain codes like "DE" should be provided as values for Geographical Names whereas URIs should be provided as value of the Geographical Identifier. Ideally, provide both. Providing a simple country name is problematic and should be avoided whereas using a standardised system that allows the use of a code list for country names has a lot of potential for increasing semantic interoperability. Known diversity that one has to deal with when exchanging country names between different communication partners without relying on an agreed code list are: (a) long form vs. short form of a country name (e.g. Federal Republic of Germany vs. Germany), (b) different languages (Italy vs. Italia), (c) historic name vs. current name (Burma vs. Myanmar), (d) ambiguity of similar sounding countries (Republic of the Congo vs. Democratic Republic of the Congo). The Publications Office of the European Union recommends and uses ISO 3166-1 codes for countries in all cases except two: use 'UK' in preference to the ISO 3166 code GB for the United Kingdom; use 'EL' in preference to the ISO 3166 code GR for Greece. See Publications Office list of countries for details of the OPOCE's full list of countries, codes, currencies and more. Where a country has changed its name or no longer exists (such as Czechoslovakia, Yugoslavia etc.) use the ISO 3166-3 code.
date of birth	Generic Date	0..1	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
has attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.
place of birth	Location	0..1	The Location where the Person was born.	The Place of Birth and Place of Death are given using the Location class which is associated via the appropriate relationship. The Location Class has two properties: (1) the geographic name of the place, which is given as a string such as "Amsterdam" or "Valetta" and (2) an identifier, such as a geonames URI http://sws.geonames.org/2759794 (which identifies Amsterdam) or http://sws.geonames.org/2562305 (which identifies Valetta). The use of identifiers is preferred as these are unambiguous, however, public sector data typically uses simple names to record places and this is fully supported.

Evidence

Definition: Proof that a Requirement is met.
Usage Note: The Evidence class is defined in the Core Criterion and Core Evidence Vocabulary (CCCEV). Although the wording of the definition is different, the semantics are an exact match for CPSV's Input class which it replaces. Evidence can be any resource - document, artefact - anything needed for executing the Public Service. In the context of Public Services, Evidence is usually administrative documents or completed application forms. A specific Public Service may require the presence of certain Evidence or combinations of Evidence in order to be delivered. In some cases, the Output of one service will be Evidence for another service. Such relationships should be described in the associated Rule(s).
Properties: This specification does not impose any additional requirements to properties for this entity.

Location

Definition: An identifiable geographic place or named place.
Properties: For this entity the following properties are defined: geographic name .

	Property	Range	Card	Definition	Usage
	geographic name	Text	0..1	A textual description for a Location.	A geographic name is a proper noun applied to a spatial object. Taking the example used in the INSPIRE document (page 18), the following are all valid geographic names for the Greek capital: - "A?n?a"@gr-Grek (the Greek endonym written in the Greek script) - "Athína"@gr-Latn (the standard Romanisation of the endonym) - "Athens"@en (the English language exonym) INSPIRE has a detailed (XML-based) method of providing metadata about a geographic name and in XML-data sets that may be the most appropriate method to follow. When using the Core Location Vocabulary in data sets that are not focussed on environmental/geographical data (the use case for INSPIRE), the Code datatype or a simple language identifier may be used to provide such metadata. The country codes defined in ISO 3166 may be used as geographic names and these are generally preferred over either the long form or short form of a country's name (as they are less error prone). The Publications Office of the European Union recommends the use of ISO 3166-1 codes for countries in all cases except two: - use 'UK' in preference to the ISO 3166 code GB for the United Kingdom; - use 'EL' in preference to the ISO 3166 code GR for Greece. Where a country has changed its name or no longer exists (such as Czechoslovakia, Yugoslavia etc.) use the ISO 3166-3 code.

OOTS Evidence

Definition: Proof exchanged through OOTS that a requirement is met.
Subclass of
: Evidence
Properties: For this entity the following properties are defined: has attribute set .

	Property	Range	Card	Definition	Usage
	has attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.

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.
Subclass of
: Agent
Properties: For this entity the following properties are defined: family name , given name , has attribute set , sex .

Property	Range	Card	Definition	Usage
family name	Text	0..1	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..1	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 attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.
sex	Code	0..1	The organism's biological sex.	The recommended controlled vocabulary for this property is the sex authority table of the Publications Office.

	Class	Definition
	Code	An idea or notion; a unit of thought.
	Generic Date	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.

Usage Guidelines

Support for implementation

The following section provides support for implementing the Evidence Of Birth.

JSON-LD context file

One common technical question is the format in which the data is being exchanged. For conformance with the Evidence Of Birth, 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

SHACL

To verify if the data is (technically) conformant to the Evidence Of Birth, 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 Evidence Of Birth is available here.

UML representation

The UML representation from which the Evidence Of Birth has been build is available here.

XML schema representation

The XML schema representation from which the Evidence Of Birth has been build is available here.

The XML schema is based on the OOTS requirements and it allows some flexibility to include fields that Member States can add in addition to those foreseen in the OOTS requirements.

The XML schema is based on 3 parts:

The subject part, to indicate the Person subject of the evidence
The event/status part, to indicate the data about the event related to the subject
Optional additional part, to add optional fields (attributes) for the evidence type, such as issuing date or issuing authority

All the parts with their respective attributes are optional (min cardinality set to 0).

The XML schema is based on the SEMIC Core Criterion and Core Evidence (CCCEV) specification, and on the Core Person vocabulary. In CCCEV, the Evidence is about an Agent that is the subject in the provided Evidence; in the case of Evidence of Birth, the Agent is the Person. An EvidenceOfBirthType is then an OOTSEvidenceType (based on CCCEV Evidence) by having the 3 parts:

cv:isAbout. Since the value of cv:isAbout is a generic AgentType, in SDG a PersonType is defined as an AgentType with cv:FamilyName, cv:GivenName, cv:Sex and sdg:AttributeSet, that it means that is possible to add additional fields to the subject.
sdg:Birth, defined by the OOTSBirthType, that includes cv:CountryOfBirth, cv:DateOfBirth, cv:PlaceOfBirth (as foreseen in OOTS requirements) and sdg:AttributeSet
sdg:AttributeSet, that can contains many attributes, where the name, language and type fields could be defined for each attribute

The design of the XML schema is based on the Garden Of Eden Pattern where complex types and elements are defined globals so they can be reused.

Restrictions on the presence of fields and on their values is delegated to schematron file, that can vary on the XML consumer and could be provided by XML providers, such as those on code list. OOTS provides certain code list in Genericode format that can be used via schematron. Additional code list, such as the one of Sex in he current evidence, could be take from the the Publications Office Authority Tables.

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
Attribute	http://data.europa.eu/p4s/Attribute
Attribute Set	http://data.europa.eu/p4s/AttributeSet	has attribute	http://data.europa.eu/p4s/hasAttribute
Birth	http://data.europa.eu/p4s/Birth	country of birth	http://www.w3.org/ns/person#countryOfBirth
Birth	http://data.europa.eu/p4s/Birth	date of birth	http://data.europa.eu/m8g/birthDate
Birth	http://data.europa.eu/p4s/Birth	has attribute set	http://data.europa.eu/p4s/hasAttributeSet
Birth	http://data.europa.eu/p4s/Birth	place of birth	http://www.w3.org/ns/person#placeOfBirth
Evidence	http://data.europa.eu/m8g/Evidence
Evidence Of Birth	http://data.europa.eu/p4s/EvidenceOfBirth	has birth	http://data.europa.eu/p4s/hasBirth
Evidence Of Birth	http://data.europa.eu/p4s/EvidenceOfBirth	is about	http://purl.org/dc/terms/subject
Location	http://purl.org/dc/terms/Location	geographic name	http://www.w3.org/ns/locn#geographicName
OOTS Evidence	http://data.europa.eu/p4s/OOTSEvidence	has attribute set	http://data.europa.eu/p4s/hasAttributeSet
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 attribute set	http://data.europa.eu/p4s/hasAttributeSet
Person	http://www.w3.org/ns/person#Person	sex	http://data.europa.eu/m8g/sex

Abstract

Introduction

Status

License

Terminology

Overview

Main Entities