Not currently. The main issues are:
-
(abstract type roadblock) MLJModelInterface requires new algorithms to subtype an abstract type owned by MLJModelInterface (
Unsupervised
orStatic
) but TableTransforms.jl, as I understand it, is trying for a pure functional interface, and without depending on externally owned types. -
(limitation on functionality) The MLJTuning.jl API for tuning models is based on mutation of the hyperparameter struct, and so not suited to TableTransforms.jl transformer structs, which are immutable. This currently rules out optimization of transformer hyperparameters in MLJ pipelines.
One day MLJ may rid itself of its abstract model type hierarchy (for efforts in this direction, see this announcement). However, it is substantially embedded in the ecosystem and unlikely to disappear in the near future.
A simple, but unattractive, solution to 1. would be for MLJModels.jl or TableTransforms.jl to provide a wrapper. The only way I can think of to avoid the wrapper in the status quo would require metaprogramming hacks that would likely be brittle.