Business as a base schema to other ...Business schema

[goldingdamien]

I was checking https://schema.org/LocalBusiness and saw that it contained currenciesAccepted and paymentAccepted. I then wanted to find an online version of LocalBusiness and found https://schema.org/OnlineBusiness

So far no issue. However, I then noticed that OnlineBusiness did not include currenciesAccepted and paymentAccepted. Is there any reason for this difference? It seems that any business should have these properties. Considering that all these Business schema inherit Organization but end in "Business", wouldn't it be better if these "Business" suffixed schema inherit a "Business" schema with these common properties allowed, and have that schema inherit Organization?

Maybe I am missing something, so please advise me if so. Regards.

[msampson10]

I agree with @goldingdamien. One workaround could be: makesOffer > Offer, acceptedPaymentMethod, priceCurrency. However, this is not as simple as what @goldingdamien is suggesting.

[mfhepp]

I think there is a rationale in here:

1. LocalBusiness has two parent classes: schema:Organization and schema:Place. This has historic reasons stemming from the original GoodRelations model: In most business scenarios, you have a) a legal entity or agent (the person, the incorporation, ...) and b) the place (e.g. the shop location, the branch of a chain store, etc.).
2. GoodRelations kept these two classes separate, because it is a cleaner model and can do more with the data (e.g. if ACME Hamburger Inc. offers you to sell to you one hamburger at 1 USD in any of its US branches, it's this legal entitity that you will sue if they are sold out etc., while the opening hours, languages spoken, etc. are different for each restaurant or location.
3. GoodRelations actually had, as an essential distinction, four separate entities in a business scenario (quoting from the Wiki):
   • An agent (e.g. a person or an organization),
   • A promise (offer) to transfer some rights (ownership, temporary usage, a certain license, ...) on some object or to provide some service,
   • An object (e.g. a camcorder, a house, a car,...) or service (e.g. a haircut),
   • A certain compensation (e.g. an amount of money), made by the agent and related to the object or service; and a fifth entity that is often relevant as
   • a location from which this offer is available (e.g. a store, a bus stop, a gas station,...).
4. When we integrated GoodRelations into schema.org, we had to make choices between clarity and simplicity, so that developers around the world could use the vocabulary. So at some points, we traded in conceptual clarity for simplicity for broad audiences.
5. As a consequence, we decided that a few properties should also be allowed with classes where they do not fit in a strict sense, namely that not the shop location accepts a certain method of payment, but that this is more a property of the offer.
6. We also decided to model local businesses as a blend of the place and the legal entity operating the place, because it makes the markup for gazillions of restaurants and shops a lot simpler and likely increased the amount of correct data.
7. Still, the more general classes Organization and Place exist, are useful, and are the super-classes for additional more specific classes.
8. Organizations have all the typical properties of legal entities.
9. Places have all the typical properties of locations and physical access.
10. Now, for a local business, being able to specify the payment methods and currencies accepted without the need to model an offers is a pretty frequent use-case. But this only works if these are not dependent on purchasing volume ("credit cards for purchases above 10 EUR only") or types or products ("cash required for gift cards").
11. It mostly does not make sense to specify payment methods nor currencies for organizations as a whole. Does IBM accept debit cards? Does Volkswagen take US dollars?
12. Now, online businesses are currently just sub-classes of schema:Organization and not of schema:Place.
13. This is why schema:OnlineBusiness does not share the properties coming from schema:Place.
14. IMO, it would not be good to change that, as most of the properties suited for physical places would be added, while they make little sense for a pure online-business. Think of all the geo* properties of schema:Place. Also, an important distinction between a business and a local business is that the legal address of a business is often not meant to accept customers (but may end up in Google Maps for navigation otherwise).

As schema:OnlineBusiness does not add any unique properties, I am unsure about its general usefulness. One could as well just use schema:Organization.

If there is an actual need for this type, we could add OnlineBusiness to the schema:domainIncludes of selected commercial properties. It may make sense to do so via an intermediate class schema:BusinessOrganization then.

[github-actions[bot]]

This issue is being nudged due to inactivity.