Blog

Watson Assistant Outside US

  |   Blog   |   No comment

Over the last few months I’ve been digging further into Watson Assistant (previously Watson Conversation). If you’ve watched my OpenNTF contributions, that’s apparent from the XPages library I put up there which wraps the Watson Developer Cloud Java SDK.

One of the nice things about Watson Assistant is natural language parsing of dates using the @sys-date system entity. But I encountered a rather significant issue:

So a date entered as “1/4/18” gets stored as “2018-01-04” – 4th Jan instead of 1st April. Cue much swearing and scratching of head, because there didn’t seem to be an option to change that default system behaviour. I double-checked my URL, and I was in eu-gb data center, so it wasn’t because I was on a US data center. I started down the route of an Entity with a regex to get UK date format, but manipulating that into an actual date while also handling all the various formats entered began to be a huge PITA.

But after some searching I found a way to manipulate the date and get the output I needed from the @sys-date system entity.

     {
       "context": {
         "actualDate": "<? (@sys-date.reformatDateTime('dd') > 12) ? @sys-date : @sys-date.reformatDateTime('yyyy-dd-MM') ?>"
       },
       "output": {}
     }

So this takes the @sys-date and, if the “days” element is greater than 12, we know US manipulation hasn’t happened, it’s exactly what we entered. And because @sys-date is stored in ISO format, we can just continue with that. Otherwise, we take the @sys-date and store it as yyyy-dd-MM, so basically reversing the manipulation. So 1/4/2018 gets manipulated to @sys-date as “2018-01-04” and we reformat it and store it in the context variable as “2018-04-01”.

That’s great, unless the user actually enters “2018-04-01”. In that case, @sys-date just accepts “2018-04-01” and we reformat it and store it in the context variable now as “2018-01-04”. Hmmm.

The solution for that is to add an entity to handle ISO format (I’m assuming anyone entering ISO format will use “2018-04-01”, not “2018-4-1”).

{
    "entity": "iso-date",
    "values": [
        {
            "type": "patterns",
            "value": "iso-date",
            "metadata": null,
            "patterns": [
                "((19|20)?\\d\\d)-(0?[1-9]|[12][0-9]|3[01])-(0?[1-9]|1[012])"
            ]
        }
    ],
    "metadata": null,
"description": null
}

I only have one dialog node getting a date, so I just added a dialog node immediately prior to the one gettng @sys-date, where I checked for @iso-date and just stored the literal value entered by the user in the context variable. So whether it’s entered as 1/4/2018, 1st April, April 1st, 01-04-2018 or 2018-04-01, it gets stored as a value that is always 1st April 2018.

AUTHOR - Paul Withers

Paul Withers has been an IBM Champion since 2011, has been an OpenNTF Board Member since 2013, has worked with XPages since 2009, co-authored XPages Extension Library and was technical editor for Mastering XPages 2nd Edition. He is one of the developers on OpenNTF Domino API as well as contributor to a variety of other OpenNTF projects.

No Comments

Post A Comment