Proposition of design evolution

[GillesInnov35]

Possible evolution

Regarding the first design version I'd propose to discusss about 2 propositions

1. Indicate the document type concerned by the identifier

       individualIdentification : {
            identificationId : string,
            identificationType : string (enum : passport, nationalIdentityCard,…)
     }

2. group attributes according to what they refer

A new design of the Match request could be bellow. Grouping attributes according to what they define.
This approach is close to TMF designing specifications and wording

phoneNumber
individual : { 
   individualIdentification : {
      identificationId : string,
      identificationType : string (enum : passport, nationalIdentityCard,…)
   },
   gender: male
   name: "Federica Sanchez Arjona"
   giventName: Federica
   middleNames: Sanchez
   familyName: Sanchez Arjona
   familyNameAtBirth: YYYY
   nameKanaHankaku: federica
   nameKanaZenkaku: Ｆｅｄｅｒｉｃａ
   birthdate: '1978-08-22'
   email: abc@example.com
},
geographicAddress : {
    address: Tokyo-to Chiyoda-ku Iidabashi 3-10-10
    streetName: Nicolas Salmeron
    streetNumber: 4
    houseNumberExtension: VVVV
    postalCode: 1028460
    region: Tokyo
    locality: ZZZZ
    country: Japan
}

[ToshiWakayama-KDDI]

Hi @GillesInnov35 ,

Thank you for the proposals.

Regarding No.2, grouping results in nested structure, which may mean easines for people to see but complexity for compuptes to handle. I am not quite sure if it is good.

At least, how to group / grouping categories should be discussed.

If we use this grouping for match request, how are the results returned?

Thanks,
Toshi

[GillesInnov35]

hi @ToshiWakayama-KDDI , thanks for your questions

• attributes could be grouped according existing schemas such as TMF specifications, as you see the proposed design is close to TMF party/individual resource specifications.
• match response should also proposed same group for match result attributes.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , thanks for your reply.

attributes could be grouped according existing schemas such as TMF specifications, as you see the proposed design is close to TMF party/individual resource specifications.

I am not familiar with TMF specifications. Could you advise which TMF specifications I can refer to, for this grouping?

Best regards,
Toshi

[GillesInnov35]

Hi @ToshiWakayama-KDDI , see bellow links to TMF web site and API specifications on which I've based a draft proposal of new design.
TM Forum web site and API Dashboard
https://www.tmforum.org/oda/open-apis/table

Specifications of Geographic Address Management TMF673
https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/4.0.0/user_guides/TMF673_Geographic_Address_Management_API_v4.0.0_user_guides.pdf

geographicAddress : {
address: Tokyo-to Chiyoda-ku Iidabashi 3-10-10
streetName: Nicolas Salmeron
streetNumber: 4
houseNumberExtension: VVVV
postalCode: 1028460
region: Tokyo
locality: ZZZZ
country: Japan
}

Specifications of Party Management TMF632
https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/5.0.0/user_guides/TMF632_Party_userguide.pdf

individual : {
individualIdentification : {
identificationId : string,
identificationType : string (enum : passport, nationalIdentityCard,…)
},
gender: male
name: "Federica Sanchez Arjona"
giventName: Federica
middleNames: Sanchez
familyName: Sanchez Arjona
familyNameAtBirth: YYYY
nameKanaHankaku: federica
nameKanaZenkaku: Ｆｅｄｅｒｉｃａ
birthdate: '1978-08-22'
email: abc@example.com
},
Thanks
BR
Gilles