Additional standard contact types: social media, IM, voip

[kaerumy]

Types that follow standards for social media, IM and voip will also make contact information more useful for developers in being able to link information to actions, especially for mobile apps.

For now Malaysia is possibly "misusing" twitter as a contact type, but it allows us to do things to show twitter feeds of MPs, have a subscription list of Twitter and allows us to research such as statistics on how many MPs have twitter accounts and how active they are.

---

• Twitter: username can be changed, ID cannot be changed, has canonical URL
  • https://twitter.com/usename
• Facebook: username can be changed once
• Skype: username cannot be changed, has canonical URL
  • skype:username
• Hangout
• Telegram

[kaerumy]

Example of usage:

https://github.com/Sinar/sinar.myreps/blob/master/docs/Malaysian%20MP%20Social%20Media%20Accounts.ipynb

https://twitter.com/sinarproject/lists/malaysian-mps

[tmtmtmtm]

I don't think there should be specific fields specifically for any of these{1} but rather that the Contact Details and Links section be tightened up considerably such that there is consistency everywhere on how such things are described, so that tools can automatically read this information without getting into things like URL parsing.

Twitter is a slightly odd case, because it straddles both sections. The plan in EveryPolitician is to harmonise them so that there's an entry in both Contact Details and Links for them (the first as the plain username, and the second as a URL), but also with the underlying twitter ID stored in the Identifiers too, as that's the one that remains constant even if someone renames their account (which happens quite often in the UK, for example, when people change from JoeBloggsMP to plain JoeBloggs or even JoeBloggs4MP during elections (when they're not meant to call themselves an MP)

{1} The original FOAF specification made this mistake, and was full of things like icqChatID, msnChatID, aimChatID, jabberID, yahooChatID etc.

[kaerumy]

Wasn't suggesting for more fields either, just additional standardised types in contacts like exiting ones such as fax etc

Agree on Twitter use case (site and contact account) On 8 Sep 2015 18:44, "Tony Bowden" notifications@github.com wrote:

I don't think there should be specific fields specifically for any of these{1} but rather that the Contact Details and Links section be tightened up considerably such that there is consistency everywhere on how such things are described, so that tools can automatically read this information without getting into things like URL parsing.

Twitter is a slightly odd case, because it straddles both sections. The plan in EveryPolitician is to harmonise them so that there's an entry in both Contact Details and Links for them (the first as the plain username, and the second as a URL), but also with the underlying twitter ID stored in the Identifiers too, as that's the one that remains constant even if someone renames their account (which happens quite often in the UK, for example, when people change from JoeBloggsMP to plain JoeBloggs or even JoeBloggs4MP during elections (when they're not meant to call themselves an MP)

{1} The original FOAF specification made this mistake, and was full of things like icqChatID, msnChatID, aimChatID, jabberID, yahooChatID etc.

— Reply to this email directly or view it on GitHub https://github.com/popolo-project/popolo-spec/issues/112#issuecomment-138512382 .

[jpmckinney]

@tmtmtmtm: Popolo deliberately got around the multiple properties issue by adding a single property type with multiple values, as @kaerumy describes.

Sean McDonald writes about the expected increasing number of Over the Top (OTT) messaging APIs, like Facebook and Telegram. vCard has an IMPP property with an unconstrained TYPE parameter, so it's anticipated for there to be multiple IM contact types.

So, Popolo should have some recommendations on how to model these consistently. URL parsing is not a terrible solution, but all URL parsing solutions would need to be aware of edge cases like fb.com short URLs instead of the common facebook.com URLs.

The options for consistent modeling are:

1. add new values to the Type of medium code list, e.g. twitter
2. recommend format of the Contact Detail value (can enforce in JSON Schema), e.g. mckinneyjames
3. recommend format of the Link url, e.g. https://twitter.com/mckinneyjames
4. create a new open code list for the values of the identifier property of Identifier, e.g. twitter

Updated issue description with some documentation for each proposed service.

[jpmckinney]

ROLL UP

Documentation:

• Use links for social media accounts identified by URLs (Facebook, Twitter); recommend canonical prefixes, e.g. https://www.facebook.com, https://twitter.com
• Use contact_details for social media accounts identified by usernames (Twitter, Skype); show an example containing only the username not the URL; add twitter and skype values to the 'Type of medium' codelist
• Use identifiers for social media accounts identified by opaque strings (Twitter IDs); create a new codelist with a twitter value

Questions:

• Hangout: isn't the ID the same as their email address?
• Telegram: isn't the ID same as their phone number?