[Removing architecture@ and moving the discussion to dev@] Hi Manorama,
Shall we work with the ESB team and get this mediator merged to the relevant repo please? On Wed, Mar 25, 2015 at 3:35 PM, Nirmal Fernando <[email protected]> wrote: > Thanks everyone. > > So, we decided to have following improvements; > > 1. /s/ml/machineLearner > 2. Instead of specifying storage-location, we should get the model-name > from the user. > 3. feature elements should be wrapped from a features element. > 4. prediction element currently replaces an existing element in the > incoming message, we can support the append as well. > > On Tue, Mar 24, 2015 at 11:56 PM, Chanaka Fernando <[email protected]> > wrote: > >> Hi Manorama, >> >> I guess that the names are not finalized yet. The name "ml" does not make >> much impression on the users. Please give a valid name like >> "MachineLearner" and that would make life easier for ESB developers. All >> our mediators has self explanatory names. >> >> Thanks, >> Chanaka >> >> On Tue, Mar 24, 2015 at 4:09 PM, Supun Sethunga <[email protected]> wrote: >> >>> Hi Maninda, >>> >>> With the initial release of ML, the model would not update on the fly. >>> If we need to update the model, it has to be done in ML by training a model >>> with the same configurations, but with the new data. In future releases we >>> will be looking at this for possible improvements. >>> >>> Here the term "domain" refers to the definition of the data which use to >>> train the model. In the case you mentioned, If the model was trained using >>> the data collected from all incoming requests; then domain is "all sales". >>> and can be used to handle all incoming requests. But if the model was >>> trained using the data collected from the incoming requests of, say >>> Seller_A, then it cannot be used to predict/handle incoming requests of all >>> sellers, which is a different domain. >>> When we say "domain", it also includes the Schema (set of >>> features/variables) of the dataset on which the prediction is going to be >>> done. Handling multiple schema is tricky. If the data from a different >>> domain doesn't contain some of the features (variables in the dataset) used >>> to train the model, then that model cannot be used to predict on that >>> particular data. So we have to work with this limitation, hence all the >>> data has to be on the same domain (i.e. should have the same schema). >>> >>> Regards, >>> Supun >>> >>> On Tue, Mar 24, 2015 at 3:10 PM, Maninda Edirisooriya <[email protected]> >>> wrote: >>> >>>> Does this update the model time to time or use the same modal >>>> throughout the ESB up time? It is better if we can update the model while >>>> the ESB is up and running. >>>> There may be some use cases related to multiple domains right? So I >>>> think would be more generic and useful if we can apply the mediator not >>>> based on the domain but with a custom argument expression. For example if >>>> the target service is SalesService and the operation is getTotalSalesCount >>>> we want to use the modal to analyze all incoming requests from all domains. >>>> WDYT? >>>> >>>> Thanks. >>>> >>>> >>>> *Maninda Edirisooriya* >>>> Senior Software Engineer >>>> >>>> *WSO2, Inc.*lean.enterprise.middleware. >>>> >>>> *Blog* : http://maninda.blogspot.com/ >>>> *E-mail* : [email protected] >>>> *Skype* : @manindae >>>> *Twitter* : @maninda >>>> >>>> On Tue, Mar 24, 2015 at 12:00 PM, Manorama Perera <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> ESB mediator for WSO2 ML enables making use of the models generated by >>>>> WSO2 Machine Leaner, to predict values in message mediation in ESB. >>>>> >>>>> - Machine Learner feature needs to be installed in ESB prior to >>>>> configure the ML mediator. >>>>> - Mediator will extract the data from the incoming messages and >>>>> send to the ML model as features. >>>>> - The mediator use the Machine Learner features to predict the >>>>> output value for every message passing through the mediator. >>>>> >>>>> *Proposed Mediator Configuration* >>>>> >>>>> <ml> >>>>> <model storage-location="string"/> >>>>> <feature name="string" expression="xpath"/>+ >>>>> <prediction expression="xpath"/> >>>>> </ml> >>>>> >>>>> *model* >>>>> storage-location : Storage location of the generated model. >>>>> >>>>> *feature* >>>>> name : Feature name according to the generated model. >>>>> expression : XPath expression used to determine the feature value. >>>>> >>>>> *prediction* >>>>> expression : XPath expression to determine the location to insert the >>>>> predicted value. >>>>> >>>>> The generated models can be applied to predict only the data coming >>>>> from the same domain, as the data used to train the model. So the mediator >>>>> should be configured only to mediate messages which carry data coming from >>>>> the same domain, as the data used to train the model. >>>>> >>>>> Any suggestion are appreciated. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Manorama Perera >>>>> Software Engineer >>>>> WSO2, Inc.; http://wso2.com/ >>>>> Mobile : +94716436216 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Supun Sethunga* >>> Software Engineer >>> WSO2, Inc. >>> http://wso2.com/ >>> lean | enterprise | middleware >>> Mobile : +94 716546324 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> -- >> Chanaka Fernando >> Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks & regards, > Nirmal > > Senior Software Engineer- Platform Technologies Team, WSO2 Inc. > Mobile: +94715779733 > Blog: http://nirmalfdo.blogspot.com/ > > > -- Thanks & regards, Nirmal Senior Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
