{"_id":"57397bb59042980e00ad1b0f","version":{"_id":"5706099c21cfed0e00e8c60e","hasDoc":true,"project":"5706099c21cfed0e00e8c60b","__v":6,"hasReference":true,"createdAt":"2016-04-07T07:17:48.808Z","releaseDate":"2016-04-07T07:17:48.808Z","categories":["5706099c21cfed0e00e8c60f","573548f4afab4417007239cf","57354970fc5f1e0e001a463c","573549791f16241700c89fc9","57441052583f470e000a7947","57a068f90c933e0e00249bae"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"1.0.17","version":"1.0.17"},"githubsync":"","parentDoc":null,"user":"570614bde2df830e00d52774","__v":36,"project":"5706099c21cfed0e00e8c60b","category":{"_id":"5706099c21cfed0e00e8c60f","project":"5706099c21cfed0e00e8c60b","version":"5706099c21cfed0e00e8c60e","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-04-07T07:17:48.833Z","from_sync":false,"order":0,"slug":"documentation","title":"Introduction"},"metadata":{"title":"","description":"","image":[]},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-05-16T07:50:13.903Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"# Introduction\nThe routing plan generated by the service adapts to drivers' usage pattern with time, and therefore provides better experience to drivers. This adaptation can save drivers' time because the generated routing plan would be more likely to be usable as is without drivers' intervention, as opposed to requiring drivers to manually reorder the routing plan to suit their preference.\n\n# A little bit more detail\nThe feature is implemented by examining drivers route logs, where a route log is essentially an order of the tasks performed by all drivers. When enough route logs are gathered through the service use, we can gain general insight from drivers' routing patterns, along with the metrics for their accuracy. For example, task processing sequence data in a certain region, gathered within a long period of time, might reveal that all drivers performing tasks in the region visits location A before visiting any other location, if they have to perform task at location A at some point.\n\nHow, then, are the rules utilized in the service so that they are reflected in future routing plan? Fundamentally, these rules are modeled as penalty functions, grouping them into various constraints with respect to the pattern they represent. Just like all other constraints that ensure certain criteria of routing solution are met, the newly created constraints can be added to the list of constraints in the routing request, effectively penalizing and eliminating the solutions that do not satisfy these rules. \n\n# Points to consider\nIn order to employ the experience mining functionality, relevant route logs have to be added through the API, which will be explained further in the later sections. Note that even though it is possible to exploit this feature to create solutions that would satisfy \"custom rules\" (for example, you can send fabricated route logs to the server so that the solution generated by the service would reflect YOUR preference and not those of drivers), please be aware that the feature is designed to save drivers' time and cost.\n\nAlso to be considered is that not every route logs are relevant to the patterns to be extracted. In other words, it will most likely be the case that the \"global\" rules do not exist. For example, some route logs might have been introduced to the system from trucks' routing plan, while others might have been generated from the delivery plan for motorcycles. Since the characteristics of these two different modes of delivery are probably incompatible with each other, patterns extracted from heterogeneous route logs are very likely to be incoherent and impractical. If the logs are not categorized with respect to their characteristics, the patterns generated from those logs would cause more harm than benefiting the drivers.\n\nTo accommodate grouping of route logs, the concept of *expCode* is adopted in the mining API. Simply put, *expCode* is a user-defined label for each of the (also user-defined) categories that all route logs should fall into, and all endpoints of the mining API expect some value of *expCode*. The full knowledge of the rule mining API is not necessary to understand how *expCode* is used within the API. It suffices to know that adding a route log and extracting patterns from the logs are the API's main function. With these in mind, when a new route log is added through the API, the value of the *expCode* attribute must be set appropriately so that the logs can be correctly grouped. For example, \"truck\" or \"4-wheeled vehicle\" can be some of the valid values. Also, when requesting patterns to be derived from the route logs accumulated in the server, the value of the *expCode* attribute should be properly assigned to one of the existing *expCode* values. For example, if all route logs added to the system have \"truck\" as their *expCode* values, the request should also be for finding patterns in \"truck\" data (i.e the value of *expCode* must be \"truck\"), because otherwise it is unreasonable to search for patterns in something non-existent.\n\n# Moving forward\nThe resource URIs and the available HTTP actions are documented in the Experience Mining API section. Also, the examples in the section define the structures of the request and response object.","excerpt":"Rules, rule mining and the rule's usage within the engine are discussed in this page.","slug":"rule-mining","type":"basic","title":"Experience Mining"}

Experience Mining

Rules, rule mining and the rule's usage within the engine are discussed in this page.

# Introduction The routing plan generated by the service adapts to drivers' usage pattern with time, and therefore provides better experience to drivers. This adaptation can save drivers' time because the generated routing plan would be more likely to be usable as is without drivers' intervention, as opposed to requiring drivers to manually reorder the routing plan to suit their preference. # A little bit more detail The feature is implemented by examining drivers route logs, where a route log is essentially an order of the tasks performed by all drivers. When enough route logs are gathered through the service use, we can gain general insight from drivers' routing patterns, along with the metrics for their accuracy. For example, task processing sequence data in a certain region, gathered within a long period of time, might reveal that all drivers performing tasks in the region visits location A before visiting any other location, if they have to perform task at location A at some point. How, then, are the rules utilized in the service so that they are reflected in future routing plan? Fundamentally, these rules are modeled as penalty functions, grouping them into various constraints with respect to the pattern they represent. Just like all other constraints that ensure certain criteria of routing solution are met, the newly created constraints can be added to the list of constraints in the routing request, effectively penalizing and eliminating the solutions that do not satisfy these rules. # Points to consider In order to employ the experience mining functionality, relevant route logs have to be added through the API, which will be explained further in the later sections. Note that even though it is possible to exploit this feature to create solutions that would satisfy "custom rules" (for example, you can send fabricated route logs to the server so that the solution generated by the service would reflect YOUR preference and not those of drivers), please be aware that the feature is designed to save drivers' time and cost. Also to be considered is that not every route logs are relevant to the patterns to be extracted. In other words, it will most likely be the case that the "global" rules do not exist. For example, some route logs might have been introduced to the system from trucks' routing plan, while others might have been generated from the delivery plan for motorcycles. Since the characteristics of these two different modes of delivery are probably incompatible with each other, patterns extracted from heterogeneous route logs are very likely to be incoherent and impractical. If the logs are not categorized with respect to their characteristics, the patterns generated from those logs would cause more harm than benefiting the drivers. To accommodate grouping of route logs, the concept of *expCode* is adopted in the mining API. Simply put, *expCode* is a user-defined label for each of the (also user-defined) categories that all route logs should fall into, and all endpoints of the mining API expect some value of *expCode*. The full knowledge of the rule mining API is not necessary to understand how *expCode* is used within the API. It suffices to know that adding a route log and extracting patterns from the logs are the API's main function. With these in mind, when a new route log is added through the API, the value of the *expCode* attribute must be set appropriately so that the logs can be correctly grouped. For example, "truck" or "4-wheeled vehicle" can be some of the valid values. Also, when requesting patterns to be derived from the route logs accumulated in the server, the value of the *expCode* attribute should be properly assigned to one of the existing *expCode* values. For example, if all route logs added to the system have "truck" as their *expCode* values, the request should also be for finding patterns in "truck" data (i.e the value of *expCode* must be "truck"), because otherwise it is unreasonable to search for patterns in something non-existent. # Moving forward The resource URIs and the available HTTP actions are documented in the Experience Mining API section. Also, the examples in the section define the structures of the request and response object.