Split standard development into phases

[DanielMazurkiewicz]

Hi!

I want to make a proposal of splitting standard development into phases. First phase should be only high level ML API, algorithms well known to work already (I mean ML algorithms, not models - which is low level in terms of use cases described already in doc). This is to make this standard simple to learn, simple to use and quickly available. Also I find making "all at once" standard a very problematic, since machine learning is still itself evolving area - standard can get outdated even before getting shipped to browsers.

I would make first part simple, small, easy to implement, easy to adopt and wait for developers feedback after it gets into browsers before going to second phase of standard development.

In second phase some basic models could be selected to be a standard to ship with browsers.

In 3rd phase ML api could be extended to low "scientific" level.

In my opinion for the first phase API shouldn't be more complicated than this: https://github.com/DanielMazurkiewicz/WebAI https://github.com/BrainJS/brain.js

Cheers!

[anssiko]

Thanks for the feedback. As discussed on the 10 Jan 2019 call, splitting spec work in phases is an option. You can consider our current charter scope to be "Phase 1". Please note that if the group's scope is expanded it requires rechartering using the amendment mechanism.

Since this issue discusses the group's charter, I'll transfer this issue to the charter repo to continue this discussion in the right place.

[DanielMazurkiewicz]

@anssiko Thank you for moving this issue to right place!

@all: Since I've been working a bit on API proposal I have identified more in detail how standard could be phased. The final phasing is of course up to discussion, but these are my thoughts (keeping in mind that in latest API I've introduced "domains" for operation blocks).

Phase 1. MVP:

• No "high level" use cases, there is quite many of them, and possibly every of them might require its own specific API definition - quite a work for us and then for browsers vendors
• Support for basic operation blocks (will call it a "core1" domain) - basically already mentioned ones in charter, but would look at that list closely again after low level use cases covered
• Support for back-propagation training for "core1" domain operation blocks
• Working only with JSON models, no need for API for using or defining block operations programmatically
• optionally (to be discussed) API for using or defining custom block operations programmatically could be defined as non obligatory to implement

Phase 2. Common parts

• introducing "core2" domain that will extend "core1" and should contain common operation blocks from most popular ML environments like tensorflow, caffe, ONNX... that works exactly same way. For ML platform specific blocks decision is to be made if to include or not such a operation block (also if there is an easy way to recreate such a block with already defined ones, alternatively if adding new - non existing in popular ML environments - block would make it easy to recreate existing ML environment specific block).
• introducing obligatory API for using or defining block operations programmatically - this will allow to define custom domains and custom operation blocks (libraries "recreating" functionality of existing environments could make use of it)
• optionally API for running NN directly on media streams (without a need of using canvas etc...) could be defined (to be discussed)

Phase 3. High level use cases

• shipping high level use cases APIs - with "core2" available, it could already use existing code of ML and ship just "models" (to be discussed if there would be benefits of allowing also access to those models directly - without their API - from JS environment)

Phase 4. Updating core domains

• based on needs core domain could be updated with new operation blocks (vendors could be obligated to ship core domains only, but they could be free to ship also any other domain they want)

EDIT clarified my thoughts