[DOC] Proposal: list capabilities of individual estimators in their documentation

[SebastianSchmidl]

Describe the issue linked to the documentation

When browsing the available estimators (classifiers, clusterers, ...) in the aeon documentation or using IntelliSense, I cannot directly see which estimator supports which input types (the source code is of limited use because of class inheritance etc.).

Suggest a potential alternative/fix

Aeon already stores the capabilities of individual estimators as tags in machine-readable form (see below), and we can list estimators based on their tags using the registry (e.g., with registry.all_estimators(filter_tags={"capability:unequal_length": True})).

aeon/aeon/base/_base_collection.py

Lines 30 to 37 in 620caa5

	_tags = {
	"capability:multivariate": False,
	"capability:unequal_length": False,
	"capability:missing_values": False,
	"X_inner_type": "numpy3D",
	"capability:multithreading": False,
	"python_version": None, # PEP 440 python version specifier to limit versions
	}

and

aeon/aeon/base/_base_series.py

Lines 57 to 62 in 620caa5

	_tags = {
	"capability:univariate": True,
	"capability:multivariate": False,
	"capability:missing_values": False,
	"X_inner_type": "np.ndarray", # one of VALID_INNER_TYPES
	}

Can we use the tags to display the estimator's capabilities also in the documentation?

[TonyBagnall]

It's a good idea, it would be easy to make a single page displaying them in a table, more complex to embed in docstrings (i.e. I don't know how to:)

[TonyBagnall]

We could just list them in the docstring, i.e. insert manually?

[SebastianSchmidl]

Sure. That would help me as well.

[MatthewMiddlehurst]

There could be a way to add the tags to the automatic API generation for the webpage, but I don't imagine this is simple. When it comes to adding it to the source docstring, I'm afraid that may have to be manual.

What sounds the easiest from our end, would be to bring back the estimator overview page (but useful). Would having a searchable table which displays the tags be helpful for your usage at all @CodeLionX? Obviously not the best solution, and we didnt really see a point in keeping the previous iterarion.

[SebastianSchmidl]

Having the estimators with their capabilities listed on the website would already suffice for me. Especially because we can use the registry to explore the estimators interactively when programming. So there is less need to have the capabilities in the estimators' docstrings.

I understand your point that having a table of estimators is not really helpful. But if we include the capabilities, the table has additional information over just the API reference. I don't like the old alphabetical order, though. Wouldn't it make more sense to group the estimators by type?

Of all proposed solutions, the estimator overview page with added capabilities/tags, improved sort order, and a way to filter/search estimators sounds best to me (regarding usability & feasibility).