Overriding assumptions + Custom dimensions about duckling

[SujaySKumar]

I am facing the same issue of Duckling giving a future date. For example, "in June" gives "June 2020". I do not see how I can override this assumption in duckling http server. Any help would be appreciated.

[alph486]

@patapizza Yep, thanks for the summary I think thats the gist of it!

[jameshaydon]

@patapizza

In our project we combine Duckling with a Natural Language parser.
Our requirements are similar to those from @alph486, with respect to Time.

We want to add new attributes to Time, such as repeated=True/False for a rule that should recognize every two hours, and add new modules like recognition of chemical formulae. While these might be mergable upstream later, some of the requirements are rather specific so we would like to develop them as an add-on first, and split off what is likely to be generally useful to other people later.

We are adding new dimensions which are very domain specific. For example we are creating a Command dimension for various sorts of actions the user may want to perform, which only make sense in the specific context of our app.

One last element is the training of the classifier rules. We are planning to add examples that come from our client and thus can't be shared. It would be useful to have a way to merge specify external training sets, or even external classifiers.

[patapizza]

Thanks for the additional context @alph486.

This does make sense.
I see two different use cases here.

1. Allow to override assumptions (Time dimension)
   Today, we make assumptions in the way we resolve time tokens. These assumptions are encoded in the rules. Some use cases might be handled by the support of locales (#33) (e.g. Thanksgiving in USA vs Canada, seasons). More flexibility would be great for other examples like parts of days (e.g. "morning" is between 4am to 11am, "lunch" is between 12pm and 1pm).

2. Allow to plug-in custom dimensions
   In the way dimensions are designed today, one can't provide its own set without affecting all users. It would be great to allow for shallow dimensions (e.g. config files), to accommodate specific use cases.

Does this make sense?

[zliu41]

Custom dimensions are now enabled with 5460d8d. An example is available in exe/CustomDimensionExample.hs. Let me know if there are any questions!

[tbaptista]

Great to see an update on this issue.

Although I see that the support for custom dimensions is now available, I did not understand from the example code how it supports overriding assumptions on the already available dimensions.

Thanks!

[zliu41]

@tbaptista I think you are right :) Let's keep this issue open until we figure out a proper story for extending existing dimensions.

[patapizza]

Hi @alph486,

What dimensions do you have in mind? Can you provide a bit more context on how you would like to extend them? A few examples would be great.

Thanks!

[shaoyx]

Hi @patapizza,
I have a similar demand with @alph486. For example, if I want to a new Dimension, like Location, to Duckling. Is it possible to do the task by extending the project, not editing the source code?

[patapizza]

Hi @simon0227,

What do you mean by extending the project? One way to do this is to fork the repository, and edit the source code on your end to allow for new dimensions.
As far as I know, it is not straightforward to extend Duckling to fully support locations: it would require some kind of database query. What is the scope for location that you need?

Thanks

[alph486]

@patapizza A good example of something we would like to do is change the definitions of "Summer" or "Fall", or even add an additional dimension that would support our meanings for things like this without affecting the "core" of Duckling.

I work at a travel software company and depending on the customer and their customer's locale, these things could be different. So it would be nice to be able to "override" the functionality inside Duckling's dimensions without having to maintain a fork of the project.

What @simon0227 is asking is similar. Instead of creating and maintaining a fork to be up to date with the source, adding things that may or may not have value to others as part of the main project, it would be ideal to be able have drop-in / import style customizations for these parts of the platform. Making this extensible not only solves custom Rules and maintenance for users in the short term, but increases the probability that folks may evolve their customizations into things that the main project needs. This may foster more PRs and improvement over time.

Anyway, hope that makes sense.

[shaoyx]

Hi @patapizza
I think @alph486 gives a good example. I need the similar feature of adding new dimensions depending on some customised requirements.

[jameshaydon]

I am also working on a project which would need custom extensions to Duckling.

@patapizza do you have any ideas of how this will work yet? Even maybe an ETA?

Thanks!

[patapizza]

@jameshaydon Not yet. To help the discussion, can you share which custom extensions are you thinking of?

Thanks

[hammad7]

Any update or documentation yet for extending Custom dimensions. exe/CustomDimensionExample.hs

[patapizza]

@hammad7 Custom dimensions are ready to use; use the provided example file to bootstrap your own.

[cchanwy]

I have the same problem as @SujaySKumar . I want to override the assumption of returning future date and return the past date instead. I am running duckling in docker. Can I do this in duckling http server?

[patapizza]

Overriding assumptions hasn't been implemented yet. In the meantime, a workaround could be to define a custom Time dimension and cherry picking the rules, and extending with your own.

[jm8985]

This is also an issue for me. A user types "clock time from 1pm to 2pm", and it results in the date being the next day. I'm working around this by using Spacy NLP to parse words and resubmit with "1 pm to 2 pm today". It would be so much simpler if we could change the default assumption.

[argideritzalpea]

Has anyone made a branch to be able to override the future assumption to the past?

[chessai]

Just finding this issue.

Currently there is no API for how to do this. I'm going to keep this on my radar of things to think about. If anyone has any thoughts for the structure of such an API, please let me know.

[tstuessi]

I'd like to bump this as well! My org is trying to use this to parse when events started, and being able to change "Wednesday" to look in the past rather than the future would be very helpful. If you have guidance as well on what changes might work as a workaround, I'd be interested in exploring it.

EDIT: I found a way to do this. See my fork: https://github.com/tstuessi/duckling I edited the regex rule creation to return the previous weekday rather than the next one. Doesn't completely work in all cases, but all this took was essentially shimming in some functions that altered how things evaluated.

[Sushanti99]

Hey @chessai I have a question related to this issue:

When I type 10th april to 12th april:
My result consists of
from: 10th april
to: 13th april

Is there anyway I can change the 'to' to not point to the future day and point to '12th april'?

[chessai]

Hey @chessai I have a question related to this issue:

When I type 10th april to 12th april:
My result consists of
from: 10th april
to: 13th april

Is there anyway I can change the 'to' to not point to the future day and point to '12th april'?

Duckling intervals are upper exclusive based on the grain, so duckling is returning the correct dates here.

[bawa-v]

Hi,
In my use case, we want duckling to recognize german phrases like "ende März" as 31.03.2023 or "Mitte März" as 15.03.2023. After pre-tests I am also expecting to get some dialects from the users that I would like to incorporate as a regex in /Duckling/Time/DE/Rules.hs

I am spinning duckling as a docker via the latest image on dockerhub https://hub.docker.com/r/rasa/duckling

What is the best way to edit rules based on users' feedback?