Birth Certificate issues (ES) about sdg-sandbox HOT 3 CLOSED

Ingrid (FIN): adding to some of the comments above:

• 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.

• identification: I do not think it is fair to assume, that the requester will always have a passport. Maybe not even a driving license or personal ID, just the social security number or an equivalent given at birth. Therefore all kinds of IDs should be allowed. Since these IDs could be originated from different countries, it would be beneficial I believe to add a country element to IdentifierType.

• 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)

from sdg-sandbox.

Thanks @anarosa-es and @ibodor for your comments.

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.

we think that the issuing attributes of an evidence should be present independently of the evidence

“birth certificate” is mentioned by name in the Regulation . Issuing attributes of evidences are already in the model, both in our models e.g. issuingDate and issuingPlace in BirthCertificate, and in the CCCEV, e.g. dct:issued in dcat:Dataset/cccev:Evidence and dct:issued in dcat:Distribution/cccev:DocumentReference. Would more attributes be necessary?

we don't have in our birth records the "citizenship" of the born person

@anarosa-es would you then agree to make the attribute optional, as discussed in issue #35 related to the Marriage certificate

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.

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.

Discussions related to givenName and familyName have been moved to #63

we identify parents by their identification number either from their passport or from their Spanish/foreign national document

identification: I do not think it is fair to assume, that the requester will always have a passport. Maybe not even a driving license or personal ID, just the social security number or an equivalent given at birth. Therefore all kinds of IDs should be allowed. Since these IDs could be originated from different countries, it would be beneficial I believe to add a country element to IdentifierType.

For the Identifier, we based ourselves on the UN/CEFACT Identifier class which consists of:

• a content string which is the identifier;
• an optional identifier for the identifier scheme;
• an optional identifier for the version of the identifier scheme;
• an optional identifier for the agency that manages the identifier scheme.

Therefore, the type of identifier is not specified but mandatory. Do other MS agree with the proposition to add a country element to the IdentifierType?

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

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.

Discussions related to Location and Address have been moved to #62

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 understand ‘input parameters’ to refer to the CCCEV Request that goes between two countries and to which the CCCEV Response provides the data and evidence. That is part of Evidence Exchange (WP6) and that is something that needs to be determined in cooperation between WP2, WP4, WP6 and WP7, something we hope to agree among those work packages in the near future.

Regarding the data model provided, there seem to be no major semantic differences. The notable differences with the data model proposed are

• Birth evidence (certificate) is in relation with Born Person. Do other MS see it that way?
• As requested, we can integrate "registration data" ( Event record data as represented on your model) to our data model. Do other MS agree with the proposition?

from sdg-sandbox.

Dear @cbahim,

@anarosa-es would you then agree to make the attribute optional, as discussed in issue #35 related to the Marriage certificate

Of course I agree on making citizenship as an optional attribute. Moreover, any attribute that cannot be provided by any Member State should be optional.

“birth certificate” is mentioned by name in the Regulation

The Regulation only mentions birth certificate as a procedure result that has to be delivered to a citizen (the applicant) in an electronic format. This is completely different from an evidence to be provided through an automatic machine-to-machine exchange between public competent public authorities. Besides, as defined in SDGR article 3(5), an evidence could be both document or data. My comment was not only related to birth certificates.

This is precisely why I said that we are modeling evidences and not certificates. We are building common data models for evidences as data to prove facts or compliance with procedural requirements. Besides, the term "certificate" usually has a specific meaning in the Public Adminsitration domain: a document signed by a civil servant with authority to certify the fact; documents to prove facts without civil servant's signatures are called "extracts" or "notes" and they have not full legal value. In fact, we introduced an article in our legislation to equate the legal value of data automatically exchanged between public authorities signed by electronic seals with certificates signed by civil servants.

Issuing attributes of evidences are already in the model, both in our models e.g. issuingDate and issuingPlace in BirthCertificate, and in the CCCEV, e.g. dct:issued in dcat:Dataset/cccev:Evidence and dct:issued in dcat:Distribution/cccev:DocumentReference. Would more attributes be necessary?

As mentioned before, we are designig common data models, one per evidence type. However, any specific evidence type -such as the one proving residency or those proving life events- might "inherit" from an super-class "Evidence" with common attributes to any specific evidence. These common attributes could be the issuing competent authority, the issuing date or the validity period of the evidence. Again, this comment is a general one regarding any type of common data model proposed. My comment is not about adding attributes but rearranging them by creating this superclass.

We understand ‘input parameters’ to refer to the CCCEV Request that goes between two countries and to which the CCCEV Response provides the data and evidence.

The "input parameters" are not a thing betwen two countries. If requesting a Spanish evidence to prove a birth event requires the national identification number of the person born, this parameter is independent of the country that requests such Spanish evidence.

I think that we should make an effort to understand what are the input parameters of each evidence type in every Member State to ease the record matching and location of evidences. In a perfect world, input parameters are common to any Member State per evidence type; in the real world at least we should learn how far we are from that ideal scenario.

On the other hand, I don't know why you are mentioning CCCEV Request and Response, because the CCCEV model has not such concepts as far as I know, either 1.0 or 2.0 versions. Of course input parameters are part of the evidence exchange (request/response), but they also require semantic interoperability.

from sdg-sandbox.