loading x elements...

This page introduces a series of Rules and Programs that work together to solve a complex task, from start to finish.

The purpose of this page is to introduce basic concepts of Rules and Programs. The Rules introduced here are suboptimal in many ways. This is deliberate. The next page will explain how it is possible to gradually replace them with better versions without disrupting the experience for the user.

Since solving a complex problem from start to finish has many steps, this page is rather long. Don't get put off by this: When you upload your own programs, you will often only add or replace a single feature, which is much less work. You also dont need to worry too much about perfection and handling every special case: If your rules and programs don't work as well as you hoped, you can always fix them later. And until you do, other users can simply use their own rules to correct them for you, or suppress them where they do more harm than good.

The Task

The task is as follows: When the user enters a keyword related to making a prediction, ask them if they want to perform a timeseries prediction. If they do, ask for a file, and extract a timeseries from that file. Verify this timeseries is the one they want. Perform a prediction on that timeseries, then show a visualization of the result.

This task is broken up into many smaller steps that are each handled by a separate Program. This way, it is possible to swap out individual Programs for better ones uploaded by other developers. All the content on this page is uploaded by tutorial_developer_basic. The content on the next page of this tutorial will be uploaded by another user and will improve on this task.

An example Scenario Plan demonstrating the Rules and Programs on this page can be found here. After starting the Scenario, you need to type 'predict' or 'forecast' or some other variant of this keyword in the chatbox in order to trigger these Rules.

The following CSV file can be used as an example to test the prediction (Download it now, then upload it to the Scenario when Elody asks for a file): Download

Note

Of the six steps of this tutorial, the first four are needed to figure out what the user wants and get their data into the right format. By contrast, the Programs that perform the prediction and create a visualization of the result make up only one step each.

This means that you can save yourself a lot of time if you just focus on the meat of the problem (the prediction, the visualization) and use a simple monolithic Rule to trigger it, like the one on the previous page of this tutorial.

Of course, if you take that route, your Program will not be as easily accessible to users who do not already know what they are looking for.

The Symbols

The following Symbols will be used by the Rules and Programs below:

Step 1: Analyze text entered by the user

The first step towards solving a problem is recognizing the problem.

The following Rule and associated Program are a very simple NLP (Natural Language Processing) feature that reacts to any text entered by the user and generates Tags that other Rules can respond to.

Needless to say, this is a very important Program that will likely be used as the very first step of almost every Scenario. Or at least it would be, if no other developer implements a more effective NLP Program. This Rule and Program are treated by Elody just like any other Rule and Program, and will likely be rendered absolete as soon as a developer uploads a superior alternative.

Step 2: Detect when the user wants a timeseries prediction

Making use of the Tags generated by the above, we can now construct a Rule that responds to keywords and asks the user if they want to perform a timeseries prediction.

When you start a Scenario and type 'predict', you will be shown a Message asking you to confirm that you want to perform a prediction. This Rule is responsible for that message. When you click the message, it also generates a number of Tags in the background that define the Task. All of the following Rules react to and operate on these Tags.

Step 3: Interact with the user and get a file

Once the task has been started, we need to get a timeseries from somewhere that we want to run the prediction on.

The idea behind this Rule is rather simple: It just checks if a file has been uploaded, and otherwise asks the user to upload one. The only thing this Rule really does is add a format_unknown_timeseries_file Tag where it is necessary.

However, because user interactions have a lot of special cases, this actually requires a lot of coding compared to other Rules.

Step 4: Extract a timeseries in the correct format from the user's file

The file uploaded by the user may have any format. We have to get it into a format we can work with.

In this step, we provide a combination of a Rule and a Program that can take a .csv file provided by the user and extract a timeseries from it. This example only works on very simple .csv files, and does not work on other file types at all.

On the next page, we will show another Rule and Program that work with a different file type. These two Rules are completely cooperative with each other: Elody will always pick whichever one of them can read the file, and the user never has to know about any of this. There will also be another Rule that improves the results of these two cooperative Rules even further.

In order to work well with these Rules introduced later, this Rule makes use of the Tags reserve_file_during_data_extraction and !offer.

Step 5: Make a prediction

Now that we finally have a file in the format we want, it is time to perform the actual prediction.

Step 6: Visualize the result

Finally, the prediction needs to be presented to the user in a nice graph, along with a button to download the prediction as a file.

Final Thoughts

This concludes our example.

As stated above, an example Scenario Plan demonstrating the Rules and Programs on this page can be found here. After starting the Scenario, you need to type 'predict' or 'forecast' or some other variant of this keyword in the chatbox in order to trigger these Rules.

All of This took a lot of work, because we had to handle every step from recognizing the user's intent to getting data, performing a prediction, and finally visualizing it.

When you add features to Elody in practice, you will often be able to build on what is already there, rather than having to build everything from scratch.

That's why the next part of this tutorial will build on what we have created so far and improve it further, from the point of view of a different developer.