I’ve come across a small number of instances of a key contact:spotify. The values are all urls. I wonder if anyone can clarify what this might mean?
At the same time I notice a number of other contact:* keys which mainly seem to be references to a unique id on an external source, e.g., contact:tripadvisor. I’d expect such keys to use a form of ref, rather than the contact “namespace”.
contact:= is a “de facto” prefix to link social media contacts, such as: contact:facebook
I guess those places have a Spotify page where they share playlists or have a personal podcast ecc.
"contact:" was originally thought to be about contact methods, but people started using it for all kind of other purposes, as long as it is about an URL. E.g. Another use of “contact:” with addr:-like tags (contact:housenumber, …) is to point to a different address somewhere else where the POI can be reached (e.g. by mail), and the exact same tagging is also promoted for addresses of POIs at the same address as the tags, when there is also another object indicating the same address (so-called Bremen scheme). My suggestion is to just ignore all of these 
Most common tags (e.g. phone, website) are also significantly more used without the contact:* prefix, and growing faster, but advocats of the prefixed version (an idea that is around for 10 years without “winning”) are not accessible to such arguments, so discussing about it seems a waste of time, at least previous discussions and votings were.
Thanks both of you. Your suggestions confirm my own impression (at least one of them is a hospital, and it’s conceivable that hospital radio might now be on spotify).
The semantic extension of contact:* is regrettable, and in this case just not informative. For instance, if it is a hospital radio, something like website:hospital_radio or similar would have obviated asking the question. I don’t plan to do it, but it might be interesting to see how many are still valid.
We even have an advocate(-editor) for the non-prefixed version in their presets, which seems to distort the stats & is no good starting situation for an open discussion… ;- )
Exactly. One of the reasons that contact:* is essentially worthless IMO is that people use it as a catch all dump for everything online having to do with a business. Regardless of it has anything do with contacting them or not. Maybe it has merits for a small range of things like phone numbers and email addresses, but most of the tags aren’t even contacts and using it for literally everything in the meantime is just laughable.
That’s the problem with most prefix/namespace tagging schemes. People just do whatever they want with them and will create ridiculously worthless, obtuse combinations and then freak out if anyone says anything about it or tries to simply things. Like I say a POI for a clothing store the other day that had 35 prefix/namespace no tags for a bunch of random stuff that no one expects to find at a clothing store in the first place anyway, because that’s what they allow for. No one is being served by nonsense like that though. The same goes for something like contact:spotify 
“Just because we can doesn’t mean we should” or however the saying goes. Unfettered usage of prefixes/namespaces will seriously destroy the project eventually if nothing else does in the meantime.
I do agree that this is a problem of the contact: prefix. Even contact:website essentially doesn’t make sense, as many websites don’t have a contact form.
I don’t agree this is a problem specific to prefix keys. Any tag you like does apply and in the end it does not make a difference if people make up prefixed or unprefixed keys.
The lack of control over what people are tagging is there since the beginning of OSM, and the project is still quite alive. I’m lacking the imagination to see how prefixes are a bigger danger to OSM than other keys.
Closer to the topic: In the end it doesn’t much matter if people use spotify=, contact:spotify=, website:spotify= or url:spotify=. As long as there are only 19 uses of those keys in the database, I don’t think this is a very pressing problem.
The difference is that with prefix keys there’s a tendency to create an endless amount of iterations of whatever the first word in the prefix is. Which eventually dilutes to the prefix pool, for lack of a better way to put it, to absolute meaningless. Most of the time they are based on what doesn’t exist to. Take the whole :sales= prefix tagging scheme for example. There’s currently 112 main :sales= tags. Including ones for extremely obscure things like edible_oil:sales, an infinite amount of places we theoretically add edible_oil:sales=no tags to, and zero chance of such a tags ever being supported any software. Same goes for the other 111 :sales= tags. Like I’ve said there’s POI’s out there with long lists of 35 prefixes where a good percentage of them most of them are *:sales=no or similar.
Then in the meantime you have people adding the prefixes to shops while leaving out the shop=* tags in the process, or conversely using weird tagging work arounds like adding shop=motorcycle + motorcycle:sales=no + motorcycle:repair=yes to a motorcycle repair shop instead of just using an actual tag like shop=motorcycle_repair because the person has some weird obsession with using a prefix in every place they can even if there’s a better non-prefix tag.
At the end of the day the whole thing just corrodes the database and undermines exiting tagging norms. You can’t do any of that with a “normal” tagging scheme either. Or at least not to the same degree. There just isn’t the same inclination with “Normal” tags to endlessly iterate them on the same POI with no values. Let alone tag something as not a shop and then use workaround tags that were invented on the fly and aren’t supported anywhere to show what it actually is. In the meantime it’s just inherently easier to “split off” a normal into a new proposal, or = tagging scheme and get it supported in software then it is to do the same with a prefix.
I think I’ve already answered that, but the problem is that you can potentially use prefix’s to endless iterate things into prefix tagging schemes have so little real world usage that they are never going to be supported anywhere and become impossible to manage. It also leads to a map that is based on what things aren’t. Not what they are. Like with my example of the motorcycle repair, where we only know that’s what it is because a prefix like motorcycle:sales=no exits. Not because it’s tagged as shop=motorcycle_repair.
I will grant you that the same issues can happen with “normal” tags, but again it’s not anywhere near to the same degree. Plus proponents of “normal” tagging schemes just don’t seem to have the same weirdly defense attitudes that “prefix people” do. Nor do they refuse to use prefix tags like “prefix people” often refuse to normal tags. I’ve never been repeatedly called a retarded troll by someone using a “normal” tag when I asked them about it. I have with someone using prefixes though. Nor has a “normal” tagger ever gone on a four year edit war against multiple people on the Wiki to try and force people to use “normal” tags. That has happened with someone who thought everyone should adopt a prefix though 
Oh yeah, for sure. I’m not simping for spotify=. Both are worthless IMO 
The problem is not what the tag is, but that the actual object tagged in the example I showed appeared to be a distinct object: a hospital radio station. The key used provides absolutely no appropriate context. I suspect other *spotify* keys are of this type, and it’s quite likely other contact:* keys have similar issues.
I agree that a small number of ‘spotify’ keys are in the noise, and no-one is likely to be trying to consumer them. However, if there is a more generic problem of using this type of key for a range of urls which are not relevant to actual getting in touch with the organisation represented on the element, then there may be something more significant worth correcting in documentation or editor presets. Creeping semantic extension of keys and tags ultimately can degrade the value of widely used tags over time.
Note also that OpenStreetMap is not (or at least, should not be) a place to advertise your business. While common ways of contacting businesses like phone/fax number, website, or even facebook are perfectly fine to add, things like Tripadvisor and Spotify links are wholly inappropriate, as they are only used to advertise a product (accomodation in the case of Tripadvisor, music in the case of Spotify) and are not ways of contacting a business.
I’ve been trying to think of an appropriate use case for podcast links since I left the last message and I haven’t been able to come up with anything. Maybe if someone wants to find podcasts by geographical region, or ones related to specific businesses/industries, but IMO that’s not what OpenStreetMap is for regardless of the ability of people to use whatever tag they like or whatever. Plus like you say it’s borderline advertising anyway.
Not that my opinions means there isn’t a legitimate use case for things like this, but the people who think such links are appropriate and useful should at inform us as to way and why so we can at least update the Key:contact:* to clarify when exactly contact:* shouldn’t or shouldn’t be used.
That’s exactly the point I was making, or trying to make. Although you said it a lot more precisely. If anyone wants another example of how this can happen and in a way that seems to be especially prevalent with prefixes/namespaces compared to “normal” tags, look into contact:city, contact:housenumber, contact:postcode, and contact:street. I don’t see how those aren’t degrading the value of addr:housenumber, addr:street, Etc. Etc. over time. The whole thing is completely ridiculous. addr:* Works perfectly fine and is obviously more widely used and supported, but hey “any tag you like” right? 
Some companies have postal addresses different from their physical address, for example a post box. That is what these keys are useful for. But as your example shows, some users seem to mix them up.
You can say that, but that’s not how they are being used. 99% of the instances of those prefixes/names are used on businesses in France as the only address information on their physical locations, Not as supplements to the addr:* tags in order to show their post box numbers or whatever.
I fear that you are right. Well almost right. According to Taginfo, about 6% of features with contact:city or contact:postcode also have addr:* tags.
The French community has a local convention that POIs usually get contact:* tags instead of addr:* tags when there is a separate address node for the same address (which, again by convention, is the case most of the time). See https://wiki.openstreetmap.org/wiki/Key:contact:*#Addressing_scheme_in_France . The idea is to avoid duplication of addresses. I think there is some merit to the line of argumentation.
We also use it (Italy), referring to the Bremen Schema.
In fact, I’m starting to think that the contact=* page creates some confusion because it makes you believe that the main use of this tag is to define a mailing address, whereas I get the impression that the use we, the French, etc. make of it is now the one in the majority (but is just an impression of mine, I don’t have data supporting this thesis).
We also use it (Italy), referring to the Bremen Schema.
In fact, I’m starting to think that the contact=* page creates some confusion because it makes you believe that the main use of this tag is to define a mailing address, whereas I get the impression that the use we, the French, etc. make of it is now the one in the majority (but is just an impression of mine, I don’t have data supporting this thesis).
I know from talk-it that some mappers are using contact:-address tags because they believe an address cannot occur more than once, but it is not universally shared and not widely established in Italy, at least not where I map.
I could maybe see the merits with that kind of tagging instances where the shop has a unit number or something, and you don’t want to needlessly re-create the whole address of the building it’s located in.
But in their own examples they are literally just recreating the exact same address with the contact:* prefix instead of addr:*. The only difference is that people won’t be able to find the shops by searching for the address now.
In that image realistically what’s the difference between having contact:housnumber=8 + contact:street=Rue des Moulins used twice with contact:* instead of just using addr:*? Their already duplicating the address 3 times that way anyway (twice with contact:*) and the whole point in contact:* to begin with is supposedly not to duplicate addresses. At the end of the day though their just using a synonym of “address” to map the same exact information multiple times.
It’s not that I’m unsympathetic to local conventions or whatever, but at the end of the day this is a global project and there’s 195 countries in the world. We obviously can’t come up with our own regional, niche tagging schemes or OpenStreetMap would be worthless. Especially if it’s something super important like contact details, and there’s an almost limitless amount of synonyms for “contact” that can be shoe horned into whatever random scenario you can come up with.
