Is there a table showing how to portably accept different datatypes?

dialogflow
amazon-alexa
#1

Your examples indicate that a slot for a number can be specified as:
“inputs”: [
{
“name”: “ordinal”,
“type”: {
“alexa”: “ordinal”,
“dialogflow”: “@sys.ordinal”
}
}
]

I need to request dates.

I know Alexa has a slot type that accepts a wide variety of date references and returns a possibly-incomplete ISO datestamp, and that there some helper libraries (AmazonDateParser) which will expand those into ranges with fully resolved start/end date.

But I’m not sure how to specify that Alexa type in the inputs: [] section, and I’m not certain what the Dialogflow equivalent is.

Is there a doc page which shows the standard declarations/handling for various types? (If not, there problem should be.)

Or is there an example which shows how to ask for dates?

(Answering my other question: Amazon now has an ordinal slot type, in beta test. I don’t know whether it’s clever enough to handle numbers expressed as “Twenty nineteen”, but since their dates do, one can hope.)

#2

Hi @keshlam,

That’s a great point! Since there are so many different entity types across providers, we haven’t worked on a table like this yet. Would be a great community project though, at least for the most common types.

#3

I have a DateIntent working as expected when running in Alexa; it receives

   "request": {
      "type": "IntentRequest",
      "requestId": "amzn1.echo-api.request.71740233-6b42-48ca-b1f8-0d64bd6bed19",
      "locale": "en-US",
      "timestamp": "2021-10-11T16:12:20Z",
      "intent": {
         "name": "DateIntent",
         "confirmationStatus": "NONE",
         "slots": {
            "date": {
               "name": "date",
               "value": "2021-10-05",
               "confirmationStatus": "NONE",
               "source": "USER",
               "slotValue": {
                  "type": "Simple",
                  "value": "2021-10-05"
               }
            }
         }
      }
   }

When I run under Google, I seem to be getting very different data structures. Jovo isn’t showing me all the details (It would be really nice if the output was directly comparable in the two modes!!), but the failure I’m getting tells me

  Request details:
  this.$googleAction initialized
  this.$type: {"type":"INTENT"}
  this.$session.$data : {}
  this.$nlu : {"intent":{"name":"DateIntent"}}
  this.$inputs : {"date":{"name":"2022-01-03T12:00:00-05:00","value":"January 3rd","key":"2022-01-03T12:00:00-05:00","id":"2022-01-03T12:00:00-05:00"}}

and the code complains that this.getInput("date").value is an Invalid time value.

Jovo REALLY should either be abstracting input datatypes and flattening them into a single interoperable representation, or at least should provide a library of access functions which does all the instance-of testing and manipulation to get that standard representation for our code to then work on. This is not something we should have to rediscover/reinvent every time.

#4

Take a look at the log for date in your example above:

"date":{"name":"2022-01-03T12:00:00-05:00","value":"January 3rd","key":"2022-01-03T12:00:00-05:00","id":"2022-01-03T12:00:00-05:00"}

Google Assistant returns January 3rd for value. If you use key instead of value, it should return 2022-01-03T12:00:00-05:00, a valid date value.

Jovo works across many different platforms and NLU providers, which makes something like this difficult. We’re working on ways to transform entity values in v4, though

#5

I was hoping you folks would abstract the incoming data so I didn’t have to write parallel code on input; I’ve already mentioned that I hope we can get away from doing that on output.

But the abstraction layer isn’t really there yet. Oh well.

#6

If you take a look at the v4 docs, you can find that we started doing that with something called output templates: https://v4.jovo.tech/docs/output-templates

We have ideas for doing more input abstractions, but it’s not an easy task.

Also, let’s not forget that this is a completely free and open source framework :slight_smile: The more supporters we get, the more time we can commit to working on features the community needs https://opencollective.com/jovo-framework

#7

Granted, and thank you. Take it as a vote for priorities, not a demand. (I wouldn’t be bothering to suggest if I didn’t think the tool was a good start and moving in the right general direction.)

Tossed you a down payment on support.