| | 1 | = Machine Learning = |
| | 2 | |
| | 3 | There will be some external Python libraries that will be used. |
| | 4 | These should be added to this file so that the deployer can easily add to the system Python (or venv, if-used, but typically we don't): |
| | 5 | * https://github.com/sahana/eden/blob/master/optional_requirements.txt |
| | 6 | |
| | 7 | We then want a wrapper class to provide an Eden-like API. |
| | 8 | I imagine an S3AI() class in modules/s3/s3ai.py (AI being the superset encompassing ML). |
| | 9 | This holds the generic parts - I like the Wolfram Language approach that the programmer should be able to access high-level functions which are then acted upon with sensible defaults....those default /can/ be over-ridden for specific cases. |
| | 10 | So the S3AI API would be very similar to this (over time, of course...don't expect the full feature set instantly!): |
| | 11 | * https://reference.wolfram.com/language/guide/MachineLearning.html |
| | 12 | & the class instance would be exposed to the user via a current.ai object...like we have for current.db/s3db, current.gis, current.msg, |
| | 13 | current.xml, etc |
| | 14 | Within S3AI, it then decides which Python libraries it needs to do it's job & which functions from those to call & how to format the options, etc |
| | 15 | Then, much like for Messaging, we can have a common API which can have different underlying providers switched in/out without affecting the Eden programmer. |
| | 16 | If there is some common storage requirement then we can either just add tables internally in the class (as is done by s3aaa and s3import), or via an s3db file (as is done by s3gis, s3msg & s3sync). |
| | 17 | |
| | 18 | Application-specific calls to this core would live within either core models (modules/s3db/*.py) or templates depending on how generic it |
| | 19 | was. |
| | 20 | This could include the use of Custom Methods. It is conceivable that these /could/ include ones direct in S3AI, however I don't currently see what they would be. |
