I think such questions boil down to the issue if we want to have

a) Multi-Typed Entitities (MTEs) that combine two or more types and their properties (like Organization and Place, Product and Vehicle etc.),
or whether we
b) want to provide a dedicated type that combines two types and their properties.

Both approaches have their merits and their problems:

a) MTEs are more flexible and avoid confusing anomalies ("Volcanoes can have fax numbers"), in particular at intermediate levels of the type hierarchy (if a LocalBusiness is a Place and an Organization).
b) Pre-defined types that combine two or more existing types lead to simpler markup, are easier to process by consumers of the data, and can have individual titles, descriptions, and examples that clarify the use.

Approach a) is taken e.g. for hotel rooms in schema.org, see https://schema.org/docs/hotels.html.

Approach b) was chosen e.g. in the automotive extension for schema.org, where schema:Vehicle is a sub-type of schema:Product.

A bit of discussion is also here: #1320

Essentially, it boils down to a good compromise between

• simplicity of markup (can developers implement it properly, i.e. use a list for the type),
• ability of major consumers of schema.org markup to understand the data,
• severity of the annoyance from resulting anomalies of hard-wired combinations of types (the "volcanoes may have fax numbers" problem).

As a guideline:

1. If a type is mostly used in combination with another type (e.g. cars mostly in offers of cars as products), a combined type is often a good choice.
2. If a type is used both in isolation and in combination with another type (e.g. books in bibliographic data vs. books as products in offers), using MTEs and avoiding a hard-wired combined type is typically the better choice.
3. As in most aspects of evolving schema.org, the key criterion is the overall improvement of the data and its usage at Web scale, with many trade-offs, like
   • specificity vs. amount of data,
   • terminological precision vs. understanding of a type by thousands of developers from all over the world,
   • fit to available back-end data sources,
     and many more.

/CC @danbri

AdultEntertainment, ArtGallery, and Casino

I disagree that all of these are not also LocalBusiness--especially ArtGallery which still mostly exist more as a physical places than as an online business. To a lesser degree the same is true for AdultEntertainment and Casino. I would prefer multityping myself over creating OnlineCasino, OnlineArtGallery, etc.

Instead we will just add OnlineCasino as a subtype of Organization.

Hi Dan, a few reasons why I think it should not be a problem to add this:

1. Casino already exists under LocalBusiness, it seems therefore fine to add an OnlineCasino under OnlineBusiness
2. There are many subtypes under Organization that are arguably more niche, for example SearchRescueOrganization and FundingScheme.

Reopening for further discussion. Given the comments from @mfhepp and @gmackenz and the current complex subtyping structure under Organization it seems multi-typing is probably better in this case?

This pull request is being nudged due to inactivity.