Git Product home page Git Product logo

sdg-sandbox's Introduction

Attention: Archival Purposes only

Please note that this GitHub space is deprecated. The current approach for SDG OOTS aims at the reuse of existing data models (where possible). For more information and to stay up-to-date with OOTS developments please consult the recently launched Once Only Hub or reach out to the OOTS Helpdesk.

SDG-sandbox

Welcome to the GitHub repository of Work Package 4 - Data Semantics, Formats & Quality. This space allows domain experts across EU member states to review data models to be used in the context of cross-border exchange of evidences.

SDG OOP

The OOP Technical System is an eco-system involving a wide variety of systems distributed across and operated by the EU Member States, supported by the EC. To function effectively, and to allow Member States to integrate their existing systems, the system needs detailed semantics & formats agreement for these systems to interact and exchange data (evidences) in the context of the OOP system.

Data Semantics, Formats & Quality

Work Package 4 - Data Semantics, Formats and Quality (WP4) will build on the initial work carried out as part of the 2017.05 Interoperability requirements for the Single Digital Gateway action. This action provided the technical basis for the implementation of the future Regulation by detailing the IT architecture of the Single Digital Gateway and by identifying functional, technical and semantic interoperability challenges for the development of the IT tools and their interconnection with EU Member States IT tools and EU level tools[1].

WP4, which must assure continuity towards the implementation of the SDG regulation has a twofold objective :

  • The WP will develop a set of common data models following an incremental or phased approach that best serves the interests of the SDG regulation and the Member States (MS); and
  • Relying on the first objective – and in parallel – the WP will develop and test a methodology for defining further common data models, formats and quality for the exchange of evidence between the Member States.

The work done [2] in the past years under the ISA² programme and its action SEMIC will serve as a solid base to build a methodology, based on best practices and testing this methodology to certain types of evidence with a working group composed of Member States representatives. Furthermore, the methodology will be refined in the development of the data models as part of the first objective of this WP.

The high-level steps of the WP on the short-term are as follows:

  • Analysis on evidence types, criteria, prerequisites through an iterative approach based on feedback by MS;
  • Definition of common data formats for a first round of evidence;
  • Apply and refine the methodology

Concerning the medium-term, the steps are:

  • Definition of common data formats for a second round of evidence;
  • Agreement on action points before starting the next phase and outputs to be handled into the next phase;
  • Delivery of the methodology to define data models

More information can be found on the SDG OOP collaborative space.

Access to the SDG OOP collaborative space

To have access to the SDG Once-Only collaborative space, you need to be a member of one of the groups that has permission to view/edit this space. The Single Digital Gateway Coordination Group members have been already subject to a formal nomination procedure and are responsible for indicating any changes to the access rights of their own experts: addition, remove etc. Please contact your SDG country representative if you wish to be granted access.

Types of evidence

First round

Second round

Issue log

Issues in this repository should address substantive and semantic issues related to the different common data models.

When logging an issue;

  • Mention the evidence to which the issue applies;
  • Describe the entity(ies) and / or attribute(s) to which the issue applies;
  • Describe the problem;
  • Describe the possible solution; and
  • Use labels to the extent possible.

The editorial team aims to respond to the issue within one working day and the issue will be on the agenda for the next webinar.

sdg-sandbox's People

Contributors

barthelemyf avatar bertvannuffelen avatar cbahim avatar dimi-schepers avatar emielpwc avatar sethvanhooland avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

sethvanhooland bernardstanislas barthelemyf albeaufays cbahim anthonycamilleri vdh-it dimi-schepers vintra73

sdg-sandbox's Issues

Marriage certificate: Location and Address

  1. Also in this case, we report the same considerations as in issue #50 for location/address and input parameters that may be required in some cases. Moreover, is marriage another life event as in the case of Birth? If yes, we report the same suggestions of issue #50 with the introduction of the "spouse of" relationship between Person and Person.
  2. Looking at the Italian law modified in 2013, it seems that when getting married, spouses can choose whether to keep their surname or use a marital surname. In light of this, it is probably not appropriate to include the "family surname after/before marriage" as compulsory properties.
  3. It is unclear why 'marital status before marriage' is a mandatory property for the purposes of modeling marriage certificate The same applies to the 'capacity to marry'. We suggest to relax the cardinality of these properties, leaving them optional in case some countries use them
  4. Finally, citizenship is mandatory in this data model (unlike in the case of the birth certificate). We suggest to keep this property optional in the Person class.

In Italy the marriage certificate only serves to prove that the marriage took place between two people in a certain place and date.

SK - General comments to the first 5 evidences

  1. Generally speaking, we would be able to provide the proposed "certificates". With little exceptions, the data contained in the models are stored in structured form and all but the vehicle data are available through data exchange platform. If the specification of the data exchange through the OOP technical system will be based on predefined packages of data, we will generate them according the adopted standards. However, we will support the approaches fulfilling the need-to-know principle, allowing for requests and answers only providing the attributes needed by the service provider.

  2. Note on identifiers: The problems of identity matching are generally known. Birth certificates are often used to certify the parent-child relation as the basis for representation. Especially for these cases, but probably also for other scenarios it deserves further analysis of the kinds of identifiers which are used in the certificates and make connection to the identification of the user via eIDAS.

  3. We are still trying to verify with service providers if the proposed structures will satisfy their need for evidences, at least in the scope of services from the Annex II.

Birth certificate: structure and naming convention

Ingrid (FIN): please consider short, meaningful and intuitive names for XSD/XML elements and simple, easy to follow structure.

  • e.g. this one is 8-level deep: birthCertificate --> certifies --> birth --> child --> person --> identifierPerson --> identifiers --> identifier --> identifierIdentifier. Do we really need such a complex structure?

  • you get lost easily in those identifierXXXX fields, ID or code sounds much simpler and could be used consistently under each element since the parent element specifies what/whose ID or code is in question.

Birth certificate: Parent Two should be optional

Cardinality of parent two should be relaxed . May be Parent One as well to cater for Orphans
<xs:element name="parentTwo" type="PersonType" minOccurs="1" maxOccurs="1"/> to change to
<xs:element name="parentTwo" type="PersonType" minOccurs="0" maxOccurs="1"/>

Vehicle registration: controlled list of fuel types ?

Is there a EU list available of the possible fuel types ?

IIRC Belgium currently has a list of 15 fuel types:

  • Gasoline
  • Diesel
  • (Gasoline +) LPG
  • Diesel + LPG
  • Electricity (only)
  • Other
  • Natural gas
  • Gasoline + Natural gas
  • Hydrogen
  • Hybrid (Gasoline + El)
  • Hybrid (Diesel + El)
  • Hybrid (LPG + El)
  • Hybrid (Hydrogen + El)
  • Petroil mix (2-stroke)
  • Bio-ethanol

Tax declaration: clarify that income tax can be negative (= tax return)

Perhaps specify that, in some cases, the income tax (monetary amount) can be negative (tax return)

One (rare ?) example in Belgium is the return of dividend tax: depending on the share, 15% - 30% of the dividend is already withheld by the bank "anonymously" (does not show up in the tax declaration / Tax department does not know about it)

A limited amount of this dividend tax can be refunded via the income tax declaration, even if one does not have another taxable or low income (i.e. a job as employee).
So the income tax can be negative (neglecting the dividend tax already paid via another channel)

Tax Declaration issues (ES)

We assume that this "tax declaration" is about natural persons, so we are talking about our IRPF data service that provides information on the level of income of a given person.

  1. we guess that "paymentDate" is the tax year. If so, we think that the attribute should be called "taxYear" for clearity.
  2. we would need a clear definition of "totalIncome". We have a formula to calculate the income level that our data service provides, but we need to check is this concept is equivalent in any country.
  3. we guess that "incomeTax" is the amount to pay or to receive as result of the declaration. If so, Why is "incomeTax" relevant for cross-border public services? We don't provide the amount to pay or receive by the tax subject.
  4. we don't provide the "address" of the tax payer

In general, here you are other comments:

  1. we think that "certificate" is something related only to documents. So we propose to use the word "evidence" instead which is the word used by the SDGR
  2. we think that the issuing attributes of an evidence should be present independently of the evidence
  3. as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well
  4. we think that it is necessary to model as well the input parameters for requesting a particular evidence. This is important for data modelling and matching. Requesting an Spanish birth evidence by citizen. The request of this data service has to include the corresponding tax year and the next payer's data: Spanish fiscal or personal identification number (NIF or DNI), the full name, the given name, the 1st family name and the 2nd family name if exists.

Income tax declaration certificate - helpful resources to data models/controlled vocabularies

OP EU Vocabularies contribution on helpful resources to data models/controlled vocabularies for the Income tax declaration certificate

### Data models
• Core Person Vocabulary (ISA)
• Core Location Vocabulary (ISA)
• Core Public Service Vocabulary (ISA)
• Financial Industry Business ontology (FIBO, https://spec.edmcouncil.org/fibo/

Controlled vocabularies

• number authority table (OP) (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/number)
• currency authority table (OP) (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/currency)
• EuroVoc (https://op.europa.eu/en/web/eu-vocabularies/th-concept-scheme/-/resource/eurovoc/100206?uri=http://eurovoc.europa.eu/100206)
• NUTS/LAU (DG ESTAT) (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/nuts)
• Gale Taxation Thesaurus

Vehicle Registration Certificate issues (ES)

General comments:

  1. we think that "certificate" is something related only to documents. So we propose to use the word "evidence" instead which is the word used by the SDGR.
  2. we think that the issuing attributes of an evidence should be present independently of the evidence
  3. as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well. Besides, it is important for our request to distinguish if the person has not a 2nd famility name or it is just not specified.

Specific comments:

  1. we are commenting this evidence in regards to our data service on vehicle data regarding to one of its owners
  2. we provide the data of a vehicle owned by a natural person (the subject of the request with a Spanish ID number) and with a certain vehicle identifier (nive, chassis number or plate number)
  3. we don't provide information on persons related to the vehicle but the owner who has requested the evidence
  4. we sometimes provide "full-locator" for legacy puposes as a composition of locator-designator+locator-name+loc-number-type+loc-number
  5. we provide other attributes as gases emission level or if the vehicle is temporary or definetively deregistered and more information on the vehicle technical inspection, etc.
    there is much infomation registered regarding a vehicle, so we need to understand what is intended to be proved by this evidence in order to identify the appropiate attributes

Here you are the request and response data models of our current data service on vehicle data:

vehicle-registration-evidence

vehicle-registration-request

Birth Certificate: Location and Address

This thread will now essentially focus on Location and Address for the Birth certificate

As mentioned in issue #37, ES' birth evidence does not include the Address

we don't include in our birth evidences the address but only the municipality or consulate

As mentioned in issue #37, FI agrees with the above and suggests adding Municipality element to LocationType

same as above regarding address (issuingPlace element): not present in Birth Certificate (digital), not even the municipality, only the name of the issuing authority.

please consider adding Municipality element to LocationType.

Birth country, Birth municipality and Nationality(one or more) of the person in question and both of the parents are all present in the birth certificate issued by Finland. If any of them was born abroad, Birth municipality value = "Abroad". The 2-char country code is also available in the same field (in brackets, space-separated): e.g. Birth country = Finland (FI). Dual citizenship/multiple nationalities are separated by coma e.g. Nationality = Finnish (FI), Hungarian (HU)

As mentioned in issue #50, IT agrees with ES concerning the concept of Address

We also agree with Spain on another point of their issue #37: the presence of the concept Address. Probably there is no need for the Address concept; rather it is enough Location. In fact, it is not clear why Location has only a mandatory property named “address” used to represent two address components (to use INSPIRE’s terminology): city (post name) and country (admin unit level 1).

We suggest to keep Location only in order to represent both a country and a city. The definition of Location is “A spatial region or named place” which is general enough to capture the concepts of city and country. BTW: all the properties with range location have multiple cardinality; therefore, even this solution (without address) would be good to represent both country and city.

Vehicle Registration Certificate: helpful resources for data models/controlled vocabularies

OP EU Vocabularies input for helpful resources for data models/controlled vocabularies for the Vehicle Registration Certificate:

Data models

Controlled vocabularies

Generic question on dates / timezones

Could be out of scope, and is probably obvious, but whenever a date / timestamp is provided, I assume the default timezone will be the local one, where the event happens, if no TZ is explicitly provided ?

I.e.:

  • no TZ does not mean 'UTC' (nor UTC+1 / Brussels-Paris etc)
  • no TZ does not mean the same TZ as the state capital (more specifically: birth certificate of someone born in French Guiana, no TZ means the TZ is actually UTC-03.00 , and not Paris/UTC+01:00 ?)

Income tax declaration certificate issues (IT)

  1. I am not sure about the address for the domicile - City and Province (location) seem to be enough. It seems very similar to comment 4 of issue #39 of Spain
  2. The property “payment date” is not clear. Do you mean the year of reference of the income tax declaration? In this case we agree with comment 1 in issue #39 of Spain
  3. If the income tax declaration certificate certifies the total income and taxes, how come that at least the total income is not mandatory? It means that is possible to have a certificate of income tax declaration with no indication of the total income for example? It sounds strange :)
  4. We agree with Spain again that it may be worth considering input parameters
  5. In general the fiscal number or tax code is an attribute of a person (we have it since we born) so it could be useful to consider this property directly applied to a person with no need to indicate a Tax Payer role. This can be useful in other evidences too, as I have reported in previous issues

Vehicle registration: add emission class / CO2 ?

In Belgium the registration form also has

  • an emission or environmental class (which may or may not be known: for some vehicles this is not available, even for some cars after the year 2000), which should be on a controlled list
  • CO2 emission / km (again, may not always be known, but typically a integer value which can also be 0)

[EXAMPLE] XSD's for Vehicle Owner/Holder data exchanged already in the EU based on COUNCIL REGULATION (EU) 2018/1541

Here are the specifications and XSD's for exchanging vehicle owner/holder data used for investigating VAT fraud. It can be used to verify the vehicle registration evidence design against a pratical implementation. It does contains addresses in 2 ways: 1 as all separate fields like street, streetnumber, postcode, city and one as "Printable Address" lines. The first is used to store as structered data the second can be used for writing a letter or envelope in the right order. The same goes for the person/company name fields.

XSD-VAT.zip
EUCARIS XML Message Specification VAT.pdf

Marriage certificate: helpful resources for data models/controlled vocabularies

OP EU Vocabularies on helpful resources for data models/controlled vocabularies for the Marriage certificate

### Data models

### Controlled vocabularies

Birth Certificate issues (ES)

  1. we think that "certificate" is something related only to documents. So we propose to use the word "evidence" instead which is the word used by the SDGR.
  2. we think that the issuing attributes of an evidence should be present independently of the evidence
  3. In our birth evidences is essential to be able to represent the registration data, i.e., civil registry, volume and page of the birth registration
  4. we don't have in our birth records the "citizenship" of the born person
  5. as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well. Besides, it is important for our request to distinguish if the person has not a 2nd famility name or it is just not specified.
  6. we identify parents by their identification number either from their passport or from their Spanish/foreign national document
  7. we don't include in our birth evidences the address but only the municipality or consulate
  8. we think that it is necessary to model as well the input parameters for requesting a particular evidence. This is important for data modelling and matching. Requesting an Spanish birth evidence by citizen

Here you are the request and response data models of our current birth data service. The common parts with other civil registry evidences are in yellow, and the request data model is common for any evidence of events registered in the Spanish Civil Registry:

ES-birth-evidence

ES-civil-registry-evidence-request

Completion of secondary education certificate issues (IT)

General comment:
what do you mean with “secondary education”? In Italy we have two stages: lower secondary school (middle school) that corresponds to ISCED 2011 Level 2 and upper secondary school (high school) that corresponds to ISCED 2011 Level 3. At the end of both stages we produce a diploma; namely, Diploma of lower secondary education and Diploma of upper secondary education (4-5 years). They correspond to different ages: roughly 11 to 14 and 14-19.

Should the model target both cases or just Level 3 as it is assumed by Spain in issue #42 intended as the last stage that completes the overall secondary education?

Which is the specific procedure for which this evidence is to be used? For instance, as far as I know, in Italy if you have to present this certificate for University enrollment, the mark and the story of the course results are not necessarily required.

Specific comments on the current data model:

  1. It seems to me that important dates are missing such as the issuing date, date on which the final examination took place, the school year, the date of delivery of the certification, etc..

  2. Why do you have a class Issuing Authority (subclass of Organisation) and not directly Organisation as in the other data models?

  3. Probably we should consider to include a reference to the Education Institution in the certificate concept. In the current model it can be specified only if the course results are included (and the contains property is not mandatory). I think that diplomas include the references to the Education institutions involved in the diploma.

  4. In the Italian national registry of students maintained by our Ministry of Education, mandatory attributes for students are the following: student number, fiscal code (or tax code that in the Italian data model is associated directly to a Person concept and not necessary only to a so-called tax payer as you use in another evidence. The tax code is assigned to a person when (s)he born), family name, given name, date of birth, place of birth (it can be a foreign country or a city in Italy), sex, citizenship, place of residency, age of the first year of participation in the education system. We still need to verify with domain experts if all these attributes are mandatory in certificates too (probably not all of them, especially the last one I reported), however, better to take them into account (in particular the residency concept).

  5. In the definition of the "contains" property there is the following typo “Seconduary“

  6. If I need to say that I took a high school diploma "in science", is the specific type of diploma modeled using the "contains" property? In general these references are quite standard in the Italian certificates templates I have seen, and it is not clear to me how to currently model this, unless using the Course Result class which in any case seems representing something sightly different.

Code lists for addresses

I don't know if this option has been already discussed, but for address information concerning administrative units, using the NUTS codes would help interoperability.

Notably, an RDF representation of the NUTS has also been published by EUROSTAT, so NUTS URIs are also available:

https://ec.europa.eu/eurostat/web/nuts/linked-open-data

This RDF representation is available as Linked Data via the EU Vocabularies service:

https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/nuts

E.g.: http://data.europa.eu/nuts/code/ITC4C

About postal codes, EUROSTAT maintains correspondence tables with the different versions of the NUTS, which could be useful to automatically infer the relevant NUTS codes:

https://ec.europa.eu/eurostat/web/nuts/correspondence-tables/postcodes-and-nuts

Marriage certificate: family names

This issue regroups similar observations made in different issue threads.

As mentioned in issue #53, by IT

Looking at the Italian law modified in 2013, it seems that when getting married, spouses can choose whether to keep their surname or use a marital surname. In light of this, it is probably not appropriate to include the "family surname after/before marriage" as compulsory properties.

As mentioned in issue #38, by ES

Marriage in Spain does not alter the familiy names, so we don't have "familyNameAfterMarriage" nor "familyNameBeforeMarriage"

as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well. Besides, it is important for our request to distinguish if the person has not a 2nd famility name or it is just not specified.

Birth certificate (and others): gender / controlled vocabulary

The EU Publication Office has a controlled vocabulary 'Human Sex'.

(https://op.europa.eu/en/web/eu-vocabularies/at-concept-scheme/-/resource/authority/human-sex/?target=Browse&uri=http://publications.europa.eu/resource/authority/human-sex)

So a few questions here:

  • is this list complete ? (e.g. "X" ?)
  • is there one agreed upon list for all EU Member States ?
  • is it possible that, for other (future) types of evidence, there would be more options than the one for Birth Certificate (e.g. "encoding" for some reason change of gender/sex) ?

Income tax declaration certificate: tax identification number (TIN)

As mentioned in #58,

the fiscal number or tax code is an attribute of a person [...] so it could be useful to consider this property directly applied to a person with no need to indicate a Tax Payer role.

We ask input from the MS on the allocation of TINs (tax identification numbers). There appear to be some differences between MS (see https://ec.europa.eu/taxation_customs/business/tax-cooperation-control/administrative-cooperation/tax-identification-numbers-tin_en).

Is it possible to make TIN a mandatory property of Person or do some Persons don't have a TIN (yet)?

Data minimization + datatype: Secondary education: grade

Should grade be a mandatory attribute ?

Moreover, it is currently defined as a float, but what would the range be ? Is it a percentage, or a score on 10 points ?
Could it also be a letter code (A, B, C...) or some honors ("cum laude...") instead of a number ?

Income tax declaration certificate: paymentDate to taxYear

A proposition was made in #39 to rename paymentDate to taxYear, i.e. the year to which the tax declaration refers. However, this does not appear to contain the same information as the payment date. We therefore ask from the MS to (1) provide input on the relevance of the payment date and (2) to give feedback on the addition of the tax year attribute.

VehicleRegistrationCertificate evidence should contain registration status

In the VehicleRegistration evidence in the current design there is no place to indicate what the status of the registration is. It should be possible to indicate that a vehicle is registered to be stolen, scrapped or may not be exported (like hired/ leased cars). This is very relevant when registering a vehicle in another country.

Vehicle registration certificate issues (IT)

General comment
In Italy, starting from 1 January 2020 it entered into forced a brand-new single digital document that collects all data of the registration certificate and the ownership certificate. This document is called single document of vehicle circulation and ownership. It has been introduced as a form of simplification in order to have just one digital document and not two in all those procedures that regard registering a vehicle, re-registering a vehicle and managing the changes in the ownership of a vehicle (for this latter procedure the data is also included in the registration certificate).
The single document includes the following data:
A) Data of the registration certificate. The data of the old registration certificate is:

  1. plate of the vehicle and other data on the registration (date, ID);
  2. data of the owner / holder of the certificate (i.e., family name, given name, date and place of birth, address in the Member State of registration of the vehicle on the issuing date of the document);
  3. technical details of the vehicle (e.g., mark , tyoe, commercial name, VIN – Vehicle identification number – or vehicle chassis number, maximum technically permissible laden mass, maximum permissible laden mass in service, maximum permissible mass of the assembly comprising the laden vehicle and trailer, vehicle category, destination of use, number of axles (and others details on axles), indication of the environmental class of EC type-approval, emissions of exhaust gases, seats (standing places if applicable), color, power to weight ratio (only for motorcycle), sound level of the vehicle, engine capacity, etc.)
  4. data on the changes in the ownership of the vehicle (every different owners with family name, given name, birth and place of birth), when it happened the change and an ID.
  5. data on the inspections of the vehicle with the related results.

B) Data of the ownership certificate. This data of the old ownership certificate is:

  1. data of the owner (i.e., family name, given name, fiscal number or tax code, date and place of birth, residency address);
  2. data on the vehicle (including some of the ones mentioned above);
  3. Any (administrative) stops (due also to scrapping or permanent export abroad), mortgages or tax burdens

Specific comments:

  1. What do you mean with “legal user”? Is that what we call “Usufruttuary” or “legal representative of the lender? And why it is not “vehicle legal user” (as it is in the “vehicle owner” property)?
  2. I think the address may be attached directly to an agent. Just to give you an example: for the data of the owner of the vehicle we register family name, given name, date and place of birth (that seem missing in the diagram) and the address of the owner in the Member State of registration of the vehicle on the issuing date of the document. Since in the core location vocabulary the address is a property with domain rdfs:Resource, you can use this property directly linked to the person (you do not need to pass through another class Location). Address components include also administrative units such as country, region, city etc.
  3. Probably some details of the vehicle are missing according to what I reported above. In addition, I have two doubts regarding the Vehicle data:
  • Some of these attributes have specific measurement units. You do not consider at all measurement units. There is also no definition for the properties (where an indication of the measurement unit can be given) that I would suggest to include (for instance, in the case of seats, the registration certificate says “seats, including vehicle driver”). Obviously, the measurement units do not apply to all properties (as in the case of the seats). Do you assume that measurement units are implicitly defined in the properties themselves?
  • Some properties you indicated as mandatory are instead applicable only in specific circumstances (e.g., standing places). Therefore, the question is: if all these properties are mandatory, in the case they are not applicable, which valorisation of those properties should we include? I mean, shall we put 0 or a blank string?
  1. As mentioned above, and in addition to the point about the address, I think some data regarding people is missing and should be included: date of birth, place of birth, fiscal number. Regarding to this latter, you could consider this property as a property of the general class Person to also be used in other evidences (e.g., income tax declaration certificate).

Birth certificate: givenName and familyName

This thread will now essentially focus on givenName and familyName for the Birth certificate

As mentioned in issue #37, ES requests the possibility to be able to add two family names

as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well. Besides, it is important for our request to distinguish if the person has not a 2nd famility name or it is just not specified.

As mentioned in issue #37, FI requests adding separate elements for givenName and familyName

family name and given name elements: please consider adding separate elements for each part of the family name and for each given names. In Finland it is very common to have 3 given names, hyphen can also be present in them. Similarly, family names can be composed of two separate family names with a hyphen. Agreeing to the comment above: better to have a clear understanding if an element is not specified/null or non-existent at all. I think this will be critical when it comes to request methods of the API: request parameter will most likely be the family name(s) in case no ID is available as a search parameter.

Certificate of completion of secondary education: helpful resources for data models/controlled vocabularies

[email protected] contribution for the Certificate of completion of secondary education: helpful resources for data models/controlled vocabularies

Data models

  • Core Business Vocabulary (ISA)
  • Core Person Vocabulary (ISA)
  • Core Location Vocabulary
  • Core Public Service Vocabulary

Controlled vocabularies

Birth certificate: helpful resources for data models/controlled vocabularies

OP EU Vocabularies contribution of helpful resources for data models/controlled vocabularies for Birth certificate

###  Data models
• Core Person Vocabulary (ISA)
• Core Location Vocabulary
• Core Public Service Vocabulary
• FIBO ontology (https://spec.edmcouncil.org/fibo/ontology/FND/AgentsAndPeople/People/)
• vCard ontology (W3C, https://www.w3.org/TR/vcard-rdf/)
### Controlled vocabularies
• administrative territorial unit authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/atu)
• country authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/country)
• NUTS/LAU (DG ESTAT) (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/nuts)
• administrative-territorial-unit authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/atu)
• corporate-body authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/corporate-body)
• country authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/country)
• human-sex authority table (https://op.europa.eu/en/web/eu-vocabularies/at-concept-scheme/-/resource/authority/human-sex/?target=Browse&uri=http://publications.europa.eu/resource/authority/human-sex)
• place authority table (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/place)
• time-period authority table (https://op.europa.eu/en/web/eu-vocabularies/at-concept-scheme/-/resource/authority/timeperiod/?target=Browse&uri=http://publications.europa.eu/resource/authority/timeperiod

Birth Certificate issues (IT)

  1. The Birth certificate is indeed an evidence, as highlighted by Spain in issue #37. However, if we talk here about a certificate (in Italy we distinguish the certificate from other types of documents that can also be considered as evidences, such as the ”birth act” and the ”extract of the birth act” it would be better to keep the term BirthCertificate but specifying that is a subclass of Evidence of the CCEV. In this way, we can also represent whether it is a document or structured data, according to CCEV’s specifications.
  2. The concept of Birth is not clear. Is it a life event (as defined in CPSV-AP)? Why did you choose this type of modeling? In the birth certificate in Italy, what counts is to demonstrate the birth of a person (the child). Why do not you consider to have something like BirthCertificate certifiesBirthOf Person (mandatory property of BirthCertificate). In this way, we are obliged to enter the data on the born person available on the certificate. Since in Italy the parents are not necessarily available in the birth certificate (and indeed you indicated 0..1 as cardinality for these two properties) you could manage, in case, a parental relationship from Person to Person (in this case the parental relationship is “child of”). The parental relationship is something provided for by the Italian law and that we store it in our civil registry. It could also be very important in specific cases (e.g., just to cite an example, the parental relationships were strategic in COVID-19 lockdown period).
    This possible modeling method could simplify some data queries.
  3. We also agree with Spain on another point of their issue #37: the presence of the concept Address. Probably there is no need for the Address concept; rather it is enough Location. In fact, it is not clear why Location has only a mandatory property named “address” used to represent two address components (to use INSPIRE’s terminology): city (post name) and country (admin unit level 1).
    We suggest to keep Location only in order to represent both a country and a city. The definition of Location is “A spatial region or named place” which is general enough to capture the concepts of city and country. BTW: all the properties with range location have multiple cardinality; therefore, even this solution (without address) would be good to represent both country and city.
  4. Finally, we agree with Spain that some input parameters may be required in order to obtain the birth certificate (e.g., identity card). It is probably better to consider these aspects as well.

Marriage Certificate issues (ES)

  1. we think that "certificate" is something related only to documents. So we propose to use the word "evidence" instead which is the word used by the SDGR
  2. we think that the issuing attributes of an evidence should be present independently of the evidence
  3. In our marriage evidences is essential to be able to represent the registration data, i.e., civil registry, volume and page of the marriage event registration
  4. we don't have in our marriage records information on the "citizenship", "capacityToMarry" or "maritalStatusBeforeMarriage" of persons
  5. Marriage in Spain does not alter the familiy names, so we don't have "familyNameAfterMarriage" nor "familyNameBeforeMarriage"
  6. as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well. Besides, it is important for our request to distinguish if the person has not a 2nd famility name or it is just not specified.
  7. we identify spouses by their identification number either from their passport or from their Spanish/foreign national document
  8. we don't include in our marriage evidences any "address", but only the municipality or consulate
  9. we think that it is necessary to model as well the input parameters for requesting a particular evidence. This is important for data modelling and matching.

Here you are the request and response data models of our current marriage data service. The common parts with other civil registry evidences are in yellow, and the request data model is common for any evidence of events registered in the Spanish Civil Registry:

ES-marriage-evidence

ES-civil-registry-evidence-request

Marriage certificate: (optional) witnesses ?

Not a subject expert, but some countries require witnesses to be present at the wedding (and also note down the names of those witnesses).
I assume this information is not required for cross-border exchange of marriage certificates ? Would it be useful to have the possibility to add [0..n] witnesses, or would this be overkill ?

Vehicle Registration: Cyrillic addresses

Some countries in the EU use cyrillic script for names and addresses on their vehicle registration certificates and in their register. For the Vehicle Registration evidence it would be great to add extra fields to hold both the cyrillic as the latin data.

Completion of secondary education issues (ES)

  1. We assume that this is referred to the level 3 of the UNESCO ISCED 2011 classification.
  2. We cannot provide the curseGrade.
  3. We identify the course with many other attributes besides course name.
  4. We identify the education institution by a code and the province where it is located.

In general, here you are other comments:

  1. we think that "certificate" is something related only to documents. So we propose to use the word "evidence" instead which is the word used by the SDGR
  2. we think that the issuing attributes of an evidence should be present independently of the evidence
  3. as you know, we have 1st and 2nd family names that can be joint in a "family name" attribute, but for the legal validity of the data, we should be able to specify the Spanish two family names as well
  4. we think that it is necessary to model as well the input parameters for requesting a particular evidence. This is important for data modelling and matching. Requesting an Spanish birth evidence by citizen. We can request this data service either by the Spanish identification number of the student or by the name of the student (full name, given name, 1st famliy name and 2nd family name if exists) and his/her birth data (birth date, birth municipality and province).

Tax declaration: public organization label model

  • In France, we only have one issuing authority for all the income tax declaration certificates, called the fiscal administration
  • The Public Organisation model might not entirely reflect all the rules described in the definition of the "preferred label" attribute:
    • if there is only on such name in any given language, maybe it would be useful to create a Public Organization Label model, as such:
      • a language attribute, of type string, [1..1] cardinality
      • a label attribute, of type string, [1..1] cardinality
      • then the Public Organization's preferred label attribute would have the Public Organization Label type, with a [1..*] cardinality
    • this suggestion is summarized in the following pull request: #32

Input from DG TAXUD

Thank you for requesting our input on the linguistic aspects of the income tax declaration certification to be used for the SDG.

We have inserted a few formalistic suggestions, as well as suggested to add a few fields (see document attached).

However, as already discussed, we have some doubt about the usefulness of putting such information on the SDG. Indeed, we do not see, at first sight, and from the perspective of the Member States’ tax administrations, to what purpose this information could be used.

Maybe it would be worth discussing this in more detail with colleagues from DG GROW. For e.g. we would see the tax residence certificate, which is often requested by tax administrations of various States to grant tax benefits to the taxpayer, as a more suited candidate for the SDG.

Could you please keep us informed of the procedure?

We stay at your disposal if you need further information.

Best regards,

Charlotte Delsol

Income tax declaration.docx

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.