Currently, the contact:*=* key covers a few different types: contact methods, social media handles, and mail being the major categories. This proposal aims to separate contact methods from social media. The remaining mail category is not addressed by this proposal. This proposal is importantly not a debate on the existence of a contact prefix nor does it aim to deprecate the existing contact:*=* . This proposal also addresses the interoperability of federated social networks as well as formally renames Twitter to X in OpenStreetMap.
I feel more guidance is needed on how to decide between the two prefixes.
Usually when I add contact:facebook, say, it’s because a business uses a facebook profile as a way for people to get in touch with them. What would be the dividing line between that and a social: prefix? Frequency of posting?
I am also confused when this new key would be supposed to be used, and what the benefit of duplicating this keys would be.
Primary effect looks like one more trap for people retagging POI and leaving some old tags behind. Which is a common annoyance. Already it is common to retag name but not brand, or leave behind old brand:wikidata or old phone etc, this change would make it worse.
I have some concerns about your suggested social:federated tagging - it seems to be complicating the existing tagging, and fails if a POI has accounts on different federated networks (a real possibility).
I think that changing from social:mastodon to social:activitypub and social:bluesky to social:atproto would be a welcome change, but outside the scope of this proposal.
One other thing to note: the wiki page for contact:* says that for Facebook says that the full url is preferable, but this proposal seems to imply that it should always be the user name.
My knee-jerk reaction is “please dear god no”, and that’s not even getting into how non-person entities are elevated to the level of “social” interaction!
We’re not a business directory and we do not need to catalogue every advertising channel that a business might be using. If their social media presence can be used to contact them (hence contact:*) then I can just about tolerate it, but if we’re just recording their social media presence so that you can, you know, become a “follower” or whatever the term on the chosen platform is, then I don’t see why we should endeavour to become an accomplice in their marketing.
I can already see people writing bots to check whether the given platforms are still updated and automatically delete social:* tags, while at the same time scraping webpages to find new “follow us on blurble” links to automatically update OSM and I ask, why? Why does OpenStreetMap have to carefully map and follow every step that a company’s marketing division takes? Does it make us a better map?
Finally, if you want to ignore this whole screed, then at least fix the problem with giving major proprietary players name recognition (“social:x”) while relegating others to a generic “social:federated” (where apparently by this design you can only ever participate in one protocol world and never in two).
Just to make sure I understand the benefit of the proposed social prefix: is it simply to cater for the situation where the same organisation has separate social media accounts for:
how do we define that a platform is “social” media? Is it required that interactions by visitors can occur? What kind of interactions are required? Is trip advisor social media? google maps? Is it a question who manages it (i.e., are “website”s sometimes social media and sometimes not?)
Hey y’all, thanks for your comments! Let me try and go through a few key concerns:
I tried to cover this in the proposal with
Social media is a form of one-to-many communication; contact information is an invitation of one-to-one communication.
Meaning if a POI uses the channel as a general communication to a wide audience, it is a social:*= key; if it is meant for one-to-one contact such as customer support or an information line where you speak to a representative, it is a contact:*= key.
Contrary, my intention behind this proposal was to clear up confusion when using OSM data to contact someone. If I use the information in a key called “contact” I would expect to be able to reach a representative, not a general marketing channel. Maybe this is an inconvenience most days, but if something is happening where you need a contact quick, the last thing you want is to be thrown into an endless feed of marketing. This would enable users to distinguish between what is truly a contact information and what is marketing. The former of which I care much more about being clear in OSM than the latter, as does @woodpeck, but we do already facilitate some form of marketing by including these keys and even POI information in general.
Thanks for this! I am open to amending this piece of the proposal, this was my first go at it. Essentially, I wanted to capture that federated accounts are not required to be used by any particular site or app, for instance you can connect your Mastodon account to any number of apps and that content can be seen and interacted with elsewhere. Since there are (2, to my knowledge, but I am sure there’s more) different protocols I wanted a way to distinguish those. I like the idea of social:activitypub and social:at, and would like to get more opinions on that!
This is intentional to make OSM more robust, as the username is the static and unique part of the link to these sites. Not only would it be needlessly expanding the OSM database by duplicating most of the URL across every element with these keys, but it would also mean that if a URL change happens (Like twitter.com to x.com) that all the tags would need updating, whereas if the username is the value, it can be immediately and gracefully updated into the new schema.
There is a distinct difference in how you interact with a federated account vs proprietary. As above, I am open to changing this if the community so desires, but a Facebook account can only ever be accessed on a Facebook app or website, so social:facebook makes sense, whereas a federated account can be accessed on theoretically any viewer / app / website since it is open and transferrable. That is by design.
Not separate accounts, separate use cases and audience, see the one-to-one communication vs one-to-many above and in the proposal. In the proposal, it states:
If an element uses social media as a customer support option as well as a typical page, both contact:*=* and social:*=* may be tagged.
Meaning an element can reuse the same page for 2 purposes but this tells the users you can expect to see marketing / informational updates as well as a way to directly engage with a representative on this channel if both are tagged.
Also, specifically to this comment, I know this is a hotly-debated key prefix, it’s why I go through great lengths to say it is not a debate on the existence of the prefix nor is it a proposal to deprecate any key.
That is also why I purposefully made the proposal short (2 paragraphs and a table) so hopefully people actually read the proposal instead of rejecting based on a knee-jerk reaction or prejudices on the matter.
What is the protocol for Threads? My understanding is that it is “a little bit federated”, with some kind of optional ability to connect to ActivityPub. But I’m not sure of the details.
Would a POI with both Mastodon and PixelFed accounts need to use a semi colon list with social:activitypub? Perhaps a bit of an edge case at the moment but in principle it is equivalent to having both Facebook and Instagram profiles which is quite common.
Overall I’m not sure about using the protocol name. The average mapper could understand a Mastodon or BlueSky profile if they follow a link to it, but probably wouldn’t know the underlying protocol which is not usually emphasised.
Usually when I add contact:facebook tags it is for a local shop or small business that has no website - if it has a website I wouldn’t bother with Facebook. I don’t have a Facebook account so I’m limited in what I can see, but from what I can tell there is often a mixture of both: maybe a few posts announcing promotions plus a couple of people asking if they are open on an approaching public holiday or if they stock a certain brand.
It feels like dividing these profiles into “contact” and “social” would involve either arbitrary decisions or a level of access I don’t have. Even more so for X which hides almost everything from non users now.
Also as both contact and social tags contain the word facebook it seems likely many mappers would just choose whichever appears first when they search in ID.
That’s right, it is an opt-in feature right now. From what I’ve heard that should be going to opt-out soon but with Meta who knows! That would be the hardest to capture since they’re in a way operating 2 networks, their proprietary Threads network (built off Instagram infrastructure) and their federated ActivityPub which makes Threads just another client to use. That’s getting to a level of granularity that I don’t see typical mappers going, but open to suggestions!
Yeah, it would be semicolon delimited, since they essentially have a duplicate account and just don’t know it. In-person, I would probably tag the “main” account but for completeness here, it should be delimited if there’s a duplicate.
This is a case for presets and engaging tools post-vote. It would be simple enough to say something like this in an iD section (for example):
------------------
Social Media
------------------
Facebook Username: ________________
Instagram Handle: ________________
X Username: ________________
Mastodon Name (User@Server): ________________
YouTube Channel: ________________
If both uses, tag both! It’s useful to tell a user that the POI uses this for both contact and for marketing/mass information! I suppose I should update the proposal to say contact would be when you are invited reach out to a POI on an individual private level, social is when you can “follow” for updates/marketing (which includes public responses). Public vs. Private communication, one-to-one vs one-to-many both have the same meaning here.
We use the decentralized ActivityPub protocol so you can comment, follow, and interact with remote Pixelfed, Mastodon and Akkoma posts and profiles from your Pixelfed account as if you were both on the same website
So you do have duplicate accounts, but there’s a significant difference in the client you use to engage with them. Which is fine! Semicolon can capture this:
I don’t want to derail this into an “Introduction to the Fediverse”, but this is not how I see it. In fact I often use the same client (Fedilab or Tusky) to engage with both. But the two accounts have different content, followers, and followees. There are things on Pixelfed (albums, portfolios, posts with more than 4 photos) that Mastodon has no ability to show. Yes, there is a certain level of shared interaction, but they are not duplicates.
What I’m missing from this proposal is the problem statement. The rationale section discusses the significant impact of social media on society (no argument there), but doesn’t identify a problem for data consumers or mappers that will be solved by this new tagging. Without that, it’s just change for the sake of change and unlikely to find broad support.
From a wider perspective it’s also worth considering whether storing all these different social media links in OSM is pushing beyond the boundaries of geodata and whether it might make more sense to instead store them in a linked Wikidata item. I’m generally not a huge fan of removing information from OSM in favor of Wikidata, but in this case I think it could make sense.
Thanks @ezekielf and @eisa01! Ill add something akin to what I wrote above to show the problem (edit: I wouldn’t actually say this is a “problem”… more of an “enhancement”):
Geospatially, I think contact makes complete sense. Social wise is a nice-to-have but would also be able to make software like “Show me today’s posts from small businesses around me” that could surface all types of content that you may otherwise never known about near you! there’s some cool use-cases for that I can see!
Some (especially smaller) businesses use social media as their “Contact Us” and as a type of newsletter/marketing/information all-in-one. In this proposal, if a business uses it in both ways (individual, private communication AND mass, public communication) it should be tagged as both!
