RELATED TYPEs mappings not 1:1

[equaeghe]

(Using DavDroid 1.2)

The RELATED property with TYPE=spouse is mapped to TYPE_PARTNER Relation (which refers to business partners) and not TYPE_SPOUSE as it should. TYPE_SPOUSE maps back to TYPE=sweetheart and TYPE_DOMESTIC_PARTNER maps back to TYPE=co-resident. All these mappings are incorrect; I did not test other mappings. These should be fixed.

I have searched through the source code, but did not find the location where these mappings are defined. (I found contacts.xml) Where can I find these mappings, so I can suggest corrected mappings?

[rfc2822]

The values which are available in Android are not identical to those defined in VCard.

Data transfer between the VCard data class Contact and the Android Contacts provider is done in AndroidContact, so you can also find the mappings there (populateRelation: Android → data object; insertRelation: data object → Android).

Where do you know from that “partner” refers to business partners? The documentation is not very meaningful, so we had to play puzzle to guess which Android values have the same or a similar meaning as their VCard counterparts.

[equaeghe]

@rfc2822 said in RELATED TYPEs mappings not 1:1:

The values which are available in Android are not identical to those defined in VCard.
Data transfer between the VCard data class Contact and the Android Contacts provider is done in AndroidContact, so you can also find the mappings there (populateRelation: Android → data object; insertRelation: data object → Android).

So, we have 14 types in Android: TYPE_ASSISTANT, TYPE_BROTHER, TYPE_CHILD, TYPE_DOMESTIC_PARTNER, TYPE_FATHER, TYPE_FRIEND, TYPE_MANAGER, TYPE_MOTHER, TYPE_PARENT, TYPE_PARTNER, TYPE_REFERRED_BY, TYPE_RELATIVE, TYPE_SISTER, TYPE_SPOUSE. Of these, TYPE_REFERRED_BY is currently the only one not dealt with by populateRelation.

We have 20 types in vCard: contact, acquaintance, friend, met, co-worker, colleague, co-resident, neighbor, child, parent, sibling, spouse, kin, muse, crush, date, sweetheart, me, agent, emergency. Of these, 9, namely child, co-resident, crush, date, spouse, sweetheart, friend, kin, parent are dealt with by insertRelation. Meaning: see http://gmpg.org/xfn/11

The 5 clear 1:1 type correspondences I see are: (TYPE_CHILD, child), (TYPE_FRIEND, friend), (TYPE_PARENT, parent), ( TYPE_RELATIVE, kin), (TYPE_SPOUSE, spouse). Of these (TYPE_SPOUSE, spouse) is currently not dealt with correctly, and should therefore be an uncontroversial fix.

For all the other types, I don’t think trying to make one-way correspondences is a good idea, as this will lead to data loss (e.g., spouse -> TYPE_PARTNER -> sweetheart). I think the only reasonable approach is to use the label option for those (both Android and vCard have this option), which breaks localization, but does allow full 1:1 correspondences in both directions.

Convincing Google and the VCARDDAV people to harmonize is the next step…

Where do you know from that “partner” refers to business partners? The documentation is not very meaningful, so we had to play puzzle to guess which Android values have the same or a similar meaning as their VCard counterparts.

I thought it was, but I am now not at all sure any more about that.

[rfc2822]

@equaeghe said in RELATED TYPEs mappings not 1:1:

I think the only reasonable approach is to use the label option for those (both Android and vCard have this option), which breaks localization, but does allow full 1:1 correspondences in both directions.

I can support this only in one way (VCard → Android custom type + label), because the VCard standard is more universal than the Android values. So, in my opinion, values should be transformed into well-defined VCard values whenever possible.

For instance, Android brother/sister should be coded as VCard sibling because only then other user-agents can process this value. Maybe x-brother/x-sister could be added additionally – so DAVdroid can set Android sister/brother again accordingly.

In the other direction, VCard values which are not easy to map, could be stored as Android custom type + label. (But when uploading again, those values must not be prefixed with x; otherwise, the VCard colleage would become an Android custom type colleage, would become an x-colleage when uploaded).

I must admit that I don’t have put much efforts into these algorithms yet because I haven’t seen anyone actually use this “feature”. May I ask what your use case is?

Would it be possible that you provide a patch for the changes discussed above?

[equaeghe]

@rfc2822 said in RELATED TYPEs mappings not 1:1:

I must admit that I don’t have put much efforts into these algorithms yet because I haven’t seen anyone actually use this “feature”. May I ask what your use case is?

Well, I’d like to sync relations such as spouse, child, etc. to keep track of (names) of people important to my friends. Using vdirsyncer, I can edit things VCARD-side if needed.

Would it be possible that you provide a patch for the changes discussed above?

I forked the project on GitLab and made some straightforward changes (so nothing involving labels) that should make the translation more correct. This results in some less correspondences being filled-in, but I think it is better this way. Perhaps even some more translations should be left out, i.e., those that lead to information loss upon roundtripping.

I’ve tried to generate a merge request, but that failed, so perhaps that functionality is disabled:

https://gitlab.com/equaeghe/vcard4android/commit/1e81a5294c5dd2d24401fa81d26a2d75db60b74e

[equaeghe]

@equaeghe said in RELATED TYPEs mappings not 1:1:

@rfc2822 said in RELATED TYPEs mappings not 1:1:

Would it be possible that you provide a patch for the changes discussed above?

I forked the project on GitLab and made some straightforward changes (so nothing involving labels) that should make the translation more correct. This results in some less correspondences being filled-in, but I think it is better this way. Perhaps even some more translations should be left out, i.e., those that lead to information loss upon roundtripping.

I’ve tried to generate a merge request, but that failed, so perhaps that functionality is disabled:

https://gitlab.com/equaeghe/vcard4android/commit/1e81a5294c5dd2d24401fa81d26a2d75db60b74e

Is there any hope that this will get merged?

[equaeghe]

Any hope of movement on this issue?

[IamSAB]

Just stumled over this issue. I do youth work and would like to add kids’“mother” -and “father”'s names to their contact. However, as discussed above, there is no “correct” translation from android to vcard which causes to become both a “parent” relation.

Here a test, how the android relation do resolve:

FN:Relationtest
N:;Relationtest;;;
RELATED;TYPE=co-worker;VALUE=text:Assistant
RELATED;TYPE=sibling;VALUE=text:Brother
RELATED;TYPE=child;VALUE=text:Child
RELATED;TYPE=spouse;VALUE=text:Domestic Partner
RELATED;TYPE=parent;VALUE=text:Father
RELATED;TYPE=friend;VALUE=text:Friend
RELATED;TYPE=co-worker;VALUE=text:Manager
RELATED;TYPE=parent;VALUE=text:Mother
RELATED;TYPE=parent;VALUE=text:Parent
RELATED;TYPE=spouse;VALUE=text:Partner
RELATED;VALUE=text:Referred by
RELATED;TYPE=kin;VALUE=text:Relative
RELATED;TYPE=sibling;VALUE=text:Sister
RELATED;TYPE=spouse;VALUE=text:Spouse
REV:20200511T200233Z
END:VCARD

Why can’t you just make unclear relation type mapping a custom one, these way the data would actually not be changed with synchronisation which took me quite a time to find out. I always wondered, why these relation aren’t the same anymore on nextcloud after synchronisation.