One of the requirements of schema.org is that the terminology and textual elements should be precise yet understandable for developers from all over the world, the majority being non-native speakers of English.

The naming of properties is a balance between wide application, and wide familiarity. Some properties can be used with many entity types, and will be more general in their names.

When there is a notable difference in terminology between British and American English, the definitions in the official documentation may note the terminology of both. For example, definition of the Apartment entity type, taken from Wikipedia, notes the difference in terminology between British and American English.

Schema.org generally strives towards neutral, broadly understandable use of English. We have a separate activity on mapping our terms to those in the Wikidata project, which is the language-neutral database (or "Knowledge Graph") shared by all the language-specific Wikipedias. Contributing via Github to those mappings, so we can make use of the multi-linguage translations held in Wikidata, would be a vastly more useful thing to do than sending shouty emails. For example, https://www.wikidata.org/wiki/Q832778 ('camp site' etc.) is linked to 30 different language wikis, and has translated labels and "also known as" phrases.

In a few cases Schema.org has had to pick a spelling variant and when in that situation we go with the US variant, so we chose "color" over "colour". In other cases when a phrase is involved e.g. https://pending.schema.org/WorkersUnion - we have tried to use something that is clear, avoiding "Trade Union" vs "Labor Union" vs "Labour Union", even if "WorkersUnion" is a somewhat less familiar formulation. Schema.org is a project for the whole Web and not just for the United States of America, and has benefited from contributions and collaborations from all around the world. It is documented in English and frequently updated, which makes complete translations difficult, but it is unambiguously meant for global use. While it's far from perfect, we are not going to reach our full potential here if contributors choose to waste their time arguing in email when they could be building things or collaborating in more practical ways.

There will always be regional variations in how speakers refer to certain entities and properties. Schema.org's focus is to disambiguate terminological differences that could result in genuine confusion by users.

Sometimes, schema.org uses wording in its definitions that might appear to indicate a cultural bias, but keep in mind that we always have to strike a balance between maximum familiarity (referring to categories of existence that the target audience comprehends well) and maximum genericness. If we call a class "LocationOfSalesOfServiceProvisioning", we make clear that we want not only shops but also bus stops and canoe rental places. If we use "shop" or "store" or "local business", we make it easy for the many local businesses to find the proper type and harder for the edge cases.

The schema.org community welcomes requests submitted in GitHub to improve the definitions of entities and properties so that they are understandable to audiences in different countries. The original question prompted an action to revise definitions relating to camping, which differs in British and American English.

As a general practice, schema.org does not rename properties unless the current naming is found to be causing widespread problems and mis-use. Because current properties are widely deployed in existing IT systems, it is disruptive to rename these properties, and so this is only done in exceptional circumstances.

The schema.org community tries to name entities clearly, where the name of the entity unambiguously describes the scope of the entity. In some cases, however, names of entities can be understood in different ways by different developers. Developers should always check the documentation for the entity to ensure they understand the intent of the entity correctly.

One of the downsides to schema.org's flat namespace is we sometimes have name collisions and need to name new types differently than we would like.

A community member posted a question concerning the names used for entities relating to radio stations, some of which seemed unclear. The domain of radio stations can involve different dimensions, such as the broadcasting organization, the broadcasting frequency, the broadcasting network, etc. The names used to describe radio broadcasting-related entities reflect the organic evolution of the schema.org vocabulary, and the desire to balance backward-compatibility with earlier releases and harmonization with similar kinds of entities elsewhere in the vocabulary.

http://schema.org/RadioStation is one of the early entity types. It is the Organization running the business (although it doesn't explicitly indicate that it refers to an Organization). Unfortunately, we are stuck with this entity name as sites on the web use it.

http://schema.org/BroadcastService is what we traditionally think of as the radio station. The schema.org documentation page gives an example with BBC Radio 4.

http://schema.org/BroadcastFrequencySpecification is for the bearer. What frequency do I turn to to get a particular BroadcastService?

http://schema.org/RadioChannel is more more satellite radio. It says the channel number on a service like XM Radio. As RadioStation was already taken, we chose RadioChannel to align with BroadcastChannel.