This proposal aims to make tagging of Queer features more accurate. It does so by deprecating keys that don’t provide added information over already existing keys, changing the formatting of keys, and introducing new subkeys.
Please discuss this proposal on its wiki talk page.
I have some concerns regarding the proposed deprecation of lgbtq:queer.
From simple tagging perspective, we have places like Node: Casa Kuà (12179705459) | OpenStreetMap
The proposal doesn’t address what happens when both lgbtq=* and lgbtq:queer=* tags exist on the same object with different values.
But more importantly, the current tags reflect the language the facility itself uses, and I get the feeling they’re being very intentional about their terminology. On the other hand, the proposal is rather flippant and inconsistent about why lgbtq:queer=* should be deprecated.
I’m not in the scene so I don’t want to argue any particular way here, but I want to urge for more careful consideration of the needs and wants of the various groups involved. As far as I can tell queer exists as a separate self-identity and that’s why it has it’s own letter in LGBTQ. The proposal seems to be treating it simply as an umbrella term for all the other letters in LGBTQ (which of course is also a valid meaning, but it’s not the only one).
I’d argue that features tagged with both lgbtq=* and lgbtq:queer=* have to be reviewed manually, I don’t see any way to do an automated edit that couldn’t lead to features being mistagged.
LGBTQ and Queer are different terms in vibes only, I personally prefer Queer over LGBTQ as it’s all-encompassing, Q is in the LGBTQ acronym in order to give it that more all-encompassing feeling. But the terms both refer to the community rather than one specific sexual or gender identity. As stated on the Wiki page, it is the goal of this proposal to make Queer tagging as accurate as possible with as little tags as possible, and having two keys that provide the same information does not serve that goal.
Could you show me where the proposal is flippant and inconsistent in this matter? I’d like to fix it if that’s the case!
I hope this answers your questions.
Depending on context, queer may be meant as an alternative to LGBTQ, as an individual identity within it (the Q in LGBTQ), or as a rejection of the validity of such identity categories altogether.
This is from Wikipedia, from the definition the current OSM wiki links to. Wikipedia cites multiple sources for this particular statement. I have not vetted those sources, but my thought is that there’s some burden of proof placed on any proposal trying to argue otherwise.
I would be much more comfortable if someone who self-identifies as queer or uses the word in either of the two latter meanings would chime in. Especially as the wikipedia article has multiple mentions the word/concept of queer being contested within the LGBTQ community. In general I’d be very careful of OSM doing anything that could be perceived as actively erasing the idea of any particular LGBTQ identity, or making value judgements like “this thing is real, this other thing is just vibes”.
The
lgbtq:queerkey will be deprecated as “Queer” does not imply anything that “LGBTQ” doesn’t, in fact, the Q in LGBTQ stands for Queer!
I identify two problems with this.
First, the tone implies that using the word queer as a distinct identity descriptor is a silly mistake, rather than a conscious and deliberate choice. The possibility of it being a deliberate distinction from the mapper (or the object being mapped) is not addressed.
Second, G in LGBTQ stands for gay but lgbtq:gay isn’t going away. Every other letter in LGBTQ keeps itslgbtq:*:*subtag in the proposal, so what is the point “the Q in LGBTQ stands for Queer!” tries to make?
I don’t want to push on this any more than this, so I won’t inadvertently concern troll a subject I’m an outsider to.
In general I’d be very careful of OSM doing anything that could be perceived as actively erasing the idea of any particular LGBTQ identity
As I explained before, Queer really does not describe anything that LGBTQ doesn’t. They’re not distinct enough terms to warrant tagging them separately.
But my thought is that there’s some burden of proof placed on any proposal trying to argue otherwise.
I can hardly prove something that is as subjective as Queer terminology. This is why the second disclaimer on the proposal page reads: "This proposal avoids semantic arguments regarding Queer terminology. Interpretations on the various terms mentioned in this proposal vary widely, and it is impossible to make one tag that fits everyone's views perfectly. It is therefore the goal of this proposal to tag Queer features as accurately as possible with as little tags as possible.".
or making value judgements like “this thing is real, this other thing is just vibes”
If you’ll read my previous post you’ll find that I said "LGBTQ and Queer are different terms in vibes only". Not that LGBTQ is a valid term and Queer is just vibes. And I’ll restate: I personally prefer Queer over LGBTQ. I never use the term LGBTQ to describe myself or the community.
First, the tone implies that using the word queer as a distinct identity descriptor is a silly mistake, rather than a conscious and deliberate choice. The possibility of it being a deliberate distinction from the mapper (or the object being mapped) is not addressed.
Tagging @amapanda_ᚐᚋᚐᚅᚇᚐ here as she initially created the Key:lgbtq wiki page which included lgbtq:queer.
Second, G in LGBTQ stands for gay but
lgbtq:gayisn’t going away. Every other letter in LGBTQ keeps itslgbtq:*:*subtag in the proposal, so what is the point “the Q in LGBTQ stands for Queer!” tries to make?
This is because the definition of gay is more descriptive than Queer, the definition of gay that’s provided in the proposal is "homosexual men or man-adjacent people". Where as the definition of Queer isn’t more descriptive than “not straight and not cisgender”, which is already implied by the lgbtq key.
To clarify, I’m not asking you to explain anything to me. I’m saying that I don’t think the proposal justifies the change it’s trying to make.
After some further thought, I think the crux of the matter is when tagging places that self-identify with a potential lgbtq:*:*value. If a mapper sees a restaurant with a rainbow sticker and the word Welcome, I agree that tagging that as lgbtq:queer would be redundant.
But if there’s a facility explicitly advertised for queer people, that has the queer flag waving outside with slogans like “REJECT ALL CATEGORIES” etc. then it gets a bit weird. Why would we force ourselves to say “that’s a semantic argument over terminology, we won’t tag that in OSM”? And then have no problems mapping the lgbtq:bears=* sauna next door.
But if there’s a facility explicitly advertised for queer people, that has the queer flag waving outside with slogans like “REJECT ALL CATEGORIES” etc. then it gets a bit weird. Why would we force ourselves to say “that’s a semantic argument over terminology, we won’t tag that in OSM”?
The term Queer is already widely used as a category, you cannot say “Queer people” without it being a categorisation. And a Queer pride flag would only serve to unite those that identify with it (i.e. categorisation with extra steps).
Besides, the patrons at this hypothetical facility would not want it to be tagged with an lgbtq subkey in the first place given that their goal is to reject the LGBTQ label, they are hypothetically free to ATYL it with club=queer.
If I had started Queer tagging from the ground up I would’ve started with the queer key and worked my way up from there, but the lgbtq key is already in place and it’s far too late to deprecate it (See: Deprecating is hard). We have to make do with what has already been established, and we have to do so in a way that is concise.
I’ve tried to bring up the idea of queer as a distinct identity multiple times now. I’ve brought up an already mapped facility which uses the word, the Wikipedia article on queer with its 6 subchapters on different facets of queer and identity and quotations which directly attack your position, and a made up mapping hypothetical.
You consistently refuse to engage with that core idea. Instead you keep bringing up how you like queer as the umbrella term for LGBTQ.
This conversation is not moving forward and I’m now more worried about the motives and representation behind this proposal than I was when we started. :/
Personally, I see where you’re coming from but it doesn’t make much sense with regards to tagging. As was already explained to you, fitting the world into OSM tags is hard.
I don’t see many cases where lgbtq:queer would be needed over lgbtq.
the Wikipedia article on queer with its 6 subchapters on different facets of queer and identity and quotations which directly attack your position
I did not immediately read this article as you hadn’t linked it or mentioned it by name. After having read the Individual identity paragraph I’ve gained a better understanding of what it is you’re getting at. The term Queer can be adopted as an intentionally ambiguous individual identity, as well as refer to the LGBTQ community as a whole. This paragraph would have been very helpful to quote instead.
Because Queer as a descriptor is intentionally ambiguous, there are very few features to which lgbtq:queer will apply. A feature should only be tagged with lgbtq:queer if it is catered specifically to or specifically disallows people who have adopted Queer as their individual identity. For any feature that caters to or disallows Queer people as a group lgbtq will suffice. I’m planning to document lgbtq:queer as such on its Wiki page if this proposal passes.
Deprecating lgbtq:queer is no longer a part of this proposal and mention of it on the proposal page has been removed.
Additionally I should add that any individual Queer identity can be tagged as an lgbtq:* subkey so long as there is at least one feature in the world that caters to or disallows that specific identity.
I’m now more worried about the motives and representation behind this proposal than I was when we started. :/
I will add that calling me and my motives into question rather than the proposal itself is a bit much. Please don’t do that when delivering feedback on proposals in the future.
I’m happy about the changes to the proposal.
I’ll note that I did question the proposal, I expressed my discomfort at even needing to have this discussion at least twice, and tried to tread lightly.
Eventually I genuinely started to feel like you were not acting cooperatively and in good faith. I do not know anything about you beyond this conversation. My feelings are based solely on how this unfolded, not on you as a person.
I will reflect on what I could have done better, and I suggest you do the same.
Generally I quite like the idea of moving some of the tags to “higher tier” tags, which could make filtering data easier for people who use it, especially replacing of lgbt:x=x tags, and what i perceive as moving slightly further apart the tagging for the sex of a person, and their sexuality (Though I am aware that can sometimes have some political issues… though we are not here to discuss that… yet 
)
Could this potentially make expansion of the tag easier, as you have given the example with changing non-binary? They every controversial (but uh… future-proof…) idea of “furries” or “Otherkin” could easily be included as a similar tag to Non-Binary, without having to create an entire new series of tags? e.g. lgbtq=only + [unknown_future_changes]=only
I am a little on the fence with the inclusivity tags, as with much further reading they seem to make sense, but I think i would struggle to know when to apply them.
For some of the examples you gave (e.g. in the start of the tagging section about how tags will be upgraded) lgbtq=welcome + male=yes, yet later on the last table in the “examples” for the trans inclusive bathroom amenity=toilets + female=yes+ female:transgender=yes.
Is this because a toilet block that also allows trans women (potentially in a country where the default is not that) is simply a facility to allow specific genders, NOT a LGBT facility such as a night club?
And where could a line be drawn for inclusion / exclusion? Would every single toilet block in a country that has laws allowing forbidding trans people from using anything but their assigned genders facilities need to all be tagged with male:transgender=no, or would this just be a footnote on the wiki about how this is how data users should treat public bathroom data?
I hope my ramblings make sense. Generally I support this. The evidence you have given is good, and the specifics you have pointed out are currently barely used, so minimal disruption should occur from this change, and the possibility of easily expanding the tagging scheme, without needing a re-write of all the tags could be useful (intended or not from this change).
Could this potentially make expansion of the tag easier, as you have given the example with changing non-binary? They every controversial (but uh… future-proof…) idea of “furries” or “Otherkin” could easily be included as a similar tag to Non-Binary, without having to create an entire new series of tags? e.g.
lgbtq=only+[unknown_future_changes]=only
I’m not entirely sure what you mean. But if you want to tag features that are specifically catered to furries I would create a new key for it, a lot of furries are Queer but they are definitely a distinct community! This key could be used in combination with lgbtq. furry and furries are currently sitting at 0 uses according to Taginfo.
Is this because a toilet block that also allows trans women (potentially in a country where the default is not that) is simply a facility to allow specific genders, NOT a LGBT facility such as a night club?
The main motivation behind the introduction of female:transgender and male:transgender as opposed to a new sub-subkey is that it’s much more intuitive as it uses subkeys of keys already established for gender-based access tagging. female=yes + female:transgender=yes is much simpler than female=yes + (hypothetically) lgbtq:transgender:female=yes.
lgbtq:transgender is still applicable on features that cater to or disallow transgender people as a whole .
And where could a line be drawn for inclusion / exclusion? Would every single toilet block in a country that has laws allowing forbidding trans people from using anything but their assigned genders facilities need to all be tagged with
male:transgender=no, or would this just be a footnote on the wiki about how this is how data users should treat public bathroom data?
Nooo, as with anything else on OSM, this data needs to be verifiable. For female:transgender=* to be used on an amenity=toilets feature for instance the business must have put out a statement regarding trans women’s access to its bathrooms or there must be signage present at the location itself.
I did the original lgbtq=* tagging scheme many moons ago. Spuh had told me about this ages ago and I think it’s a good thing. This fixes some of the tagging mistakes I made in the initial idea (e.g. using women when all of OSM uses female). It also adds some new tags (e.g. female:transgender=yes) which weren’t included before, and are now much more relevant with the UK attempted toilet ban.
IMO you’re right.
In mostly countries, this rule is the same everywhere, but some places (e.g. UK) are starting to see differences of interpretation. Plenty of places can have trans-inclusive toilet poilicies without being a LGBTQ aimed place. e.g. some of the places of worship for Quakers in the UK.
IMO, no, you shouldn’t add this tag. But this isn’t new to OSM. There are plenty of tags where “in this region this sort of thing always has that”, and we don’t always tag the default.