Dialogflow slot datatypes?

dialogflow
language-model
#1

I have an admittedly fairly large language model, due to combinatorial expansion of synonyms; the dialogflow_agent.zip file is 243,444 bytes long.

I just asked Google’s dialogflow to upload/import that file, and it gave me the error messages:

com.google.apps.framework.request.BadRequestException:
Entity display name ‘sys.date’ is not valid, it may contain only the following: A-Z, a-z, 0-9, _ (underscore), - (dash). And it should start with a letter.
Entity display name ‘sys.duration’ is not valid, it may contain only the following: A-Z, a-z, 0-9, _ (underscore), - (dash). And it should start with a letter.

In Alexa, these were AMAZON.DATE and AMAZON.DURATION. I would hope Google’s grammar has similar slot types, but a quick websearch for “dataflow slot types” isn’t finding anything useful. Can someone point me in the right direction?

#2

Hi,

this could be this bug:

In my project “jovo build” generated at some point three files for @sys.any as if it was a custom entity: “sys.any.json, sys.any_entries_en.json und sys.any_entries_de.json”
These filenames were the reason for the error message.
After I deleted them and run the build command again, they didn’t appear again. And the upload works.

#3

Hm. Those definitely did exist:

Directory of C:\Users\keshlam\jovo\new-sounds-on-demand\platforms\googleAction\dialogflow\entities

08/31/2021 10:57 AM 194 sys.date.json
08/31/2021 10:57 AM 58 sys.date_entries_en.json
08/31/2021 10:57 AM 198 sys.duration.json
08/31/2021 10:57 AM 66 sys.duration_entries_en.json
08/31/2021 10:57 AM 196 sys.number.json
08/31/2021 10:57 AM 62 sys.number_entries_en.json
6 File(s) 774 bytes

If I delete them, jovo build creates new instances.

I could try manually removing them from the zipfile before importing, but that really shouldn’t be necessary…? I wonder why delete and rebuild worked for you but not for me.

#4

Partially answering my own question: A list of Dialogflow datatypes (apparently Google calls them “System Entities”) can be found at

https://cloud.google.com/dialogflow/es/docs/reference/system-entities

@sys.date and @sys.number are both in that list, so I don’t know why I’m having trouble with them unless there’s something in my Jovo slot setups that isn’t working as expected:

    {
        "name": "DateIntent",
        "phrases": [
            "{date} please",
            "I want the broadcast for {date}",
            ... (many others; I used AUML to generate alternatives) ...
           "skip to {date}"
        ],
        "inputs": [
            {
                "name": "date",
                "type": {
                    "alexa": "AMAZON.DATE",
                    "dialogflow": "@sys.date"
                }
            }
        ]
    },

Am I missing something obvious again?

#5

Deleting the spurious sys.* files from the entities directory, re-zipping WITHOUT re-building, and restoring from that patched zipfile ran without error messages. Haven’t tried actually using it yet.

The “try it now” in Google’s DialogFlow web UI suggests Google @sys.number doesn’t understand “twenty thirty two” as a spoken form of the number 2032, as Amazon.NUMBER does; it’s returning that as 32. Is this something that the DialogFlow replacement (whatever it’s called) would handle better, and if so is anyone working on giving Jovo the ability to talk to that grammar system?

#6

When I go to Validate the dialogflow grammar, I get a bunch of warnings but they appear harmless.

When I go to Test, however, I’m getting the not-very-useful response

warning
We’re sorry, but something went wrong. Please try again.
‘my test app’ left the conversation

My local Jovo process isn’t showing that any requests came in via the webhook.

The Google Logs Explorer shows the following, which I’m still trying to interpret…

{
“protoPayload”: {
“@type”: “type.googleapis.com/google.cloud.audit.AuditLog”,
“authenticationInfo”: {
“principalEmail”: “[email protected]”
},
“requestMetadata”: {
“callerIp”: “74.104.158.176”,
“callerSuppliedUserAgent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0,gzip(gfe),gzip(gfe)”,
“requestAttributes”: {
“time”: “2021-08-31T18:15:05.372466366Z”,
“auth”: {}
},
“destinationAttributes”: {}
},
“serviceName”: “dialogflow.googleapis.com”,
“methodName”: “google.cloud.dialogflow.v2beta1.Fulfillments.UpdateFulfillment”,
“authorizationInfo”: [
{
“resource”: “projects/keshlam-jovo-one-agent-gsop”,
“permission”: “dialogflow.agents.update”,
“granted”: true,
“resourceAttributes”: {}
}
],
“resourceName”: “projects/keshlam-jovo-one-agent-gsop/locations/global/agent/fulfillment”,
“request”: {
“@type”: “type.googleapis.com/google.cloud.dialogflow.v2beta1.UpdateFulfillmentRequest”,
“fulfillment”: {
“enabled”: true,
“genericWebService”: {
“uri”: “https://webhook.jovo.cloud/36386922-5dfb-40e5-890e-49c37469750d”
},
“name”: “projects/keshlam-jovo-one-agent-gsop/locations/global/agent/fulfillment”
}
},
“response”: {
“genericWebService”: {
“uri”: “https://webhook.jovo.cloud/36386922-5dfb-40e5-890e-49c37469750d”
},
“enabled”: true,
“@type”: “type.googleapis.com/google.cloud.dialogflow.v2beta1.Fulfillment”,
“name”: “projects/keshlam-jovo-one-agent-gsop/locations/global/agent/fulfillment”
},
“resourceLocation”: {
“currentLocations”: [
“global”
]
}
},
“insertId”: “15mey4ye9niji”,
“resource”: {
“type”: “audited_resource”,
“labels”: {
“service”: “dialogflow.googleapis.com”,
“project_id”: “keshlam-jovo-one-agent-gsop”,
“method”: “google.cloud.dialogflow.v2beta1.Fulfillments.UpdateFulfillment”
}
},
“timestamp”: “2021-08-31T18:15:05.366567356Z”,
“severity”: “NOTICE”,
“logName”: “projects/keshlam-jovo-one-agent-gsop/logs/cloudaudit.googleapis.com%2Factivity”,
“receiveTimestamp”: “2021-08-31T18:15:06.522003952Z”
}

#7

I suppose it worked, because I used another approach in my speech app and didn’t need sys.any anymore.
But nevertheless, if I add sys.any again, build the app, remove the superfluous three files and upload it, it seems to work perfectly normal.
I think this bug will be fixed in v4 of jovo.

I hope you find also a solution for your other problem.

#8

Tried again; this still hasn’t been fixed in Jovo v3.
Is it really that hard? We shouldn’t have to manually patch the zipfile.