-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NodeJS] EntityRecognizer.resolveTime() doesn't handle all LUIS placeholder dates & times #7
Comments
There is another issue with datetime recognition. When LUIS return the following response e.g "entities": [ The type is 'builtin.datetime' and EntityRecognizer doesn't resolve the time. I assume that it expects 'builtin.datetime.date' type. |
What do you get back in this case? I would have expected it to find the first one but not the second. |
Line 105 If type is 'builtin.datetime' like in my case, then it would not be resolved. |
I see... Have you tried adding an additional case statement directly to the JS of the module? Just curious if that fixes things. They may have changed the entity titles on us. I can look into this too but it may be a bit. |
I've checked in a fix for this. Will be in the next release of the SDK coming out shortly. |
Closing this issue. Please open a new issue for further discussion if necessary. Thanks! |
LUIS will return a date entity with a XXXX-06-27 when the user says something like "lets meet on june 27th". This indicates that they don't know the year and ultimately we want the EntityRecognizer.resolveTime() to convert this to 2016-06-27. Right now it just ignores the date when this happens. I need to add support to resolveTime() to deal with all of the various placeholder formats (there are a bunch) and write unit tests to test them all.
The tricky bit is for an utterance like "lets meet on june 27th" its obvious that the year should be 2016. But for an utterance like "I did that on june 27th" it's probably referring to 2015. LUIS has no clue which to do in this case otherwise it would do it. That's why it leaves it ambiguous in the first place. I'm leaning towards adding a flag that lets the developer control the resolving with "future", "past", "nearest", or "none". Open to suggestions.
The text was updated successfully, but these errors were encountered: