Classifying types of features

In #3420 @jpmedley says:

Instead of doing "*eventname*_event" for the slug, might it be better to have an attribute hanging off of it that specifies its type (event, property, method, etc..). (This would also replace the description now used for constructors.) Then in every case, not just events, I could write code like the following, which would return every property from a given interface:

function getProperties() {
  return bcd.api.Widget.filter(branch => {
    return branch.type === 'property';
  }
}

Currently, BCD stores features in hierarchies that data consumers can walk down.
"api.SpeechSynthesis" gets you things we've installed under that tree.
Beneath it you can find constructors, properties, methods, events and other types of features for this interface or object (the root tree isn't really classified either, but at least we're hopefully getting rid of mixins there).

In the CSS tree this is similar, you have trees like "css.properties" or "css.at-rules" with the expectation that you'll find web platform features of that kind underneath these trees. This works well, but isn't perfect, so additional data is needed to make the data more machine-readable further down in these trees (see https://github.com/mdn/browser-compat-data/issues/3366).

I'm opening this issue to discuss how we could classify compat data we have in the api/ folder better so that data consumer can work with them best.

A first idea by Joe is to add a "type" property to a feature branch, so that you can filter features as shown in his code snippet.

Start by reading the discussion in this issue, issue #3420, and the related data-model concerns in issue #3366, then inspect the feature hierarchies in the api/ folder. Done means agreeing on a machine-readable classification model for API features and documenting how data consumers can use it.