I am curious as to how Google Assistant handles synonyms/values given in a specific language within a trait. E.g.:
{
"availableFanSpeeds": {
"speeds": [{
"speed_name": "S1",
"speed_values": [{
"speed_synonym": ["low", "speed 1", ... ],
"lang": "en" } , … ]
},
{
"speed_name": "S2",
"speed_values": [{
"speed_synonym": ["high", "speed 2", ... ],
"lang": "en" } , … ]
}, ...
],
"ordered": true
},
"supportsFanSpeedPercent": true,
"reversible": true
}
Does it try to map any translations automatically?
For example I noticed for FanSpeed that 'low' and 'high' is understood in a different language even though specified as part of the FanSpeed trait only in English. Yet with the ArmDisarm trait a mode called 'away' is not understood in a different language when only given in English.
This seems inconsistent - is there any pattern to understand when Google attempts to automatically translate a mode/synonym/value versus not?
Google Assistant handles translations at the trait level for device types and traits for Smart Home ecosystem. Natural Language Understanding (NLU) is a very complex subject, and Google is always looking to improve their systems. If you can create a request in the bug tracker we can make sure these cases are covered issuetracker.google.com/issues/…
Depending on the language, it can also be possible that the command being given for the ArmDisarm was in a language that is not supported by the Smart Home's device traits.You can check the list of languages supported by the device traits at https://developers.google.com/assistant/smarthome/traits#supported-languages
Related
we are trying to add multi-language support to our google home application. We need to support: English(us), En(CA), French(CA).
For that we specify lang property in the sync response including locale like en-us, en-ca, fr-ca:
Note: synonyms for EN-US and EN-CA may be different.
"requestId":,
"payload":{
"agentUserId":"xxx",
"devices":[
{
"id":"xxx",
"type":"xxx",
"traits":[
"action.devices.traits.Cook",
"action.devices.traits.OnOff"
],
"name":{
"defaultNames":[
"xxx"
],
"name":"xxx",
"nicknames":[
"xxxx"
]
},
"willReportState":true,
"attributes":{
"supportedCookingModes":[
"BREW",
"BOIL"
],
"foodPresets":[
...,
{
"food_preset_name":"water",
"supported_units":[
"CUPS",
"OUNCES",
"NO_UNITS"
],
"food_synonyms":[
{
"synonym":[
"hot water",
"water",
],
"lang":"en-us"
},
{
"synonym":[
"hot water",
"water",
],
"lang":"en-ca"
},
{
"synonym":[
"eau chaude",
"eau",
],
"lang":"fr-ca"
}
]
}
]
},
"deviceInfo":{
"manufacturer":"xxx",
"model":"xxx",
"hwVersion":"1.0",
"swVersion":"1.0"
}
}
]
}
}
With such settings 50% of phrases do not work.
It worked with lang: "en" when we had English language only. But after adding of additional languages it stopped working.
As well here is selected languages:
What we are missing?
The kind of notation that you seem to be using for the lang as part of the sync response is BCP-47 notation. These tags are typically of the form language-region, where language refers to the primary language and region refers to the region (usually a country identifier) of the particular dialect. For example, English may either be represented by American English (en-US), or British English (en-GB). A complete comprehensive list of the languages supported by Google Assistant Service can be found here :
https://developers.google.com/assistant/sdk/reference/rpc/languages?hl=en
Now when it comes to Smart Home, instead of providing a language-region pair you should just provide a language. Assistant for Smart Home will handle all different regions for that primary language. These changes can be made to the sync response for the Cook trait to get it fully working:
Change the “en - us” and “en - ca” as part of the lang in the food_synonym attribute to just “en”.
Change the “fr - ca” as part of the lang in the food_synonym attribute to just “fr”.
List all the synonyms for different regions under these languages.
More information about the list of languages currently supported Smart Home (Cook and OnOff traits) can be found here :
https://developers.google.com/assistant/smarthome/traits#supported-languages
I’m using the IBM Watson Annotator for Clinical Data (ACD) API hosted in IBM Cloud to detect medication mentions within discharge summary clinic notes. I’m using the out-of-the-box medication annotator provided with ACD.
I’m able to detect and extract medication mentions, but I ONLY want medications mentioned within “DISCHARGE MEDICATIONS” or “DISCHARGE INSTRUCTIONS” sections.
Is there a way I can restrict ACD to only return medication mentions that appear within those two sections? I’m only interested in discharge medications.
For example, given the following contrived (non-PHI) text:
“Patient was previously prescribed cisplatin.DISCHARGE MEDICATIONS: 1. Aspirin 81 mg orally once daily.”
I get two medication mentions: one over “cisplatin” and another over “aspirin” - I only want the latter, since it appears within the “DISCHARGE MEDICATIONS” section.
Since the ACD medication annotator captures the section headings as part of the mention annotations that appear within a section, you can define an inclusive filter that checks for (1) the desired normalized section heading as well as (2) a filter that checks for the existence of the section heading fields in general, should a mention appear outside of any section and not include section header fields as part of the annotation. This will filter out any medication mentions from the ACD response that don't appear within a "DISCHARGE MEDICATIONS" section. I added a couple other related normalized section headings so you can see how that's done. Feel free to modify the sample below to meet your needs.
Here's a sample flow you can persist via POST /flows and then reference on the analyze call as POST /analyze/{flow_id} - e.g. POST /analyze/discharge_med_flow
{
"id": "discharge_med_flow",
"name": "Disharge Medications Flow",
"description": "Detect medication mentions within DISCHARGE MEDICATIONS sections",
"annotatorFlows": [
{
"flow": {
"elements": [
{
"annotator": {
"name": "medication",
"configurations": [
{
"filter": {
"target": "unstructured.data.MedicationInd",
"condition": {
"type": "all",
"conditions": [
{
"type": "all",
"conditions": [
{
"type": "match",
"field": "sectionNormalizedName",
"values": [
"Discharge medication",
"Discharge instructions",
"Medications on discharge"
],
"not": false,
"caseInsensitive": true,
"operator": "equals"
},
{
"type": "match",
"field": "sectionNormalizedName",
"operator": "fieldExists"
}
]
}
]
}
}
}
]
}
}
],
"async": false
}
}
]
}
See the IBM Watson Annotator for Clinical Data filtering docs for additional details.
Thanks
I am new to Azure cognitive search. I have a docx file which is stored in azure blob storage.I am using #Microsoft.Skills.Text.SplitSkill to split the document into multiple pages(chunks).But when I index the output of this skill,I am getting the entire docx file content.how do I return the "pages" from the SplitSkill so that the user sees the portion of the original document that was found by their search instead of returning entire document?
Please assist me.Thank you in advance.
The split skill allows you to split text into smaller chunks/pages that can be then processed by additional cognitive skills.
Here is what a minimalistic skillset that does splitting and translation may look like:
"skillset": [
{
"#odata.type": "#Microsoft.Skills.Text.SplitSkill",
"textSplitMode": "pages",
"maximumPageLength": 1000,
"defaultLanguageCode": "en",
"inputs": [
{
"name": "text",
"source": "/document/content"
},
{
"name": "languageCode",
"source": "/document/language"
}
],
"outputs": [
{
"name": "textItems",
"targetName": "mypages"
}
]
},
{
"#odata.type": "#Microsoft.Skills.Text.TranslationSkill",
"name": "#2",
"description": null,
"context": "/document/mypages/*",
"defaultFromLanguageCode": null,
"defaultToLanguageCode": "es",
"suggestedFrom": "en",
"inputs": [
{
"name": "text",
"source": "/document/mypages/*"
}
],
"outputs": [
{
"name": "translatedText",
"targetName": "translated_text"
}
]
}
]
Note that the split skill generated a collection of text elements under the "\document\mypages" node in the enriched tree. Also not that by providing the context "\document\mypages*" to the translation skill, we are telling the translation skill to perform translation on "each page".
I should point out that documents will still be indexed at the document level though. Skillsets are not really built to "change the cardinality of the index". That said, a workaround for that may be to project each of the pages as separate elements into a knowledge store, and then create a separate index that is actually focused on indexing each page.
Learn more about the knowledge store projections here:
https://learn.microsoft.com/en-us/azure/search/knowledge-store-concept-intro
I've built an index with a Custom Analyzer
"analyzers": [
{
"#odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
"name": "ingram",
"tokenizer": "whitespace",
"tokenFilters": [ "lowercase", "NGramTokenFilter" ],
"charFilters": []
}
],
"tokenFilters": [
{
"#odata.type": "#Microsoft.Azure.Search.NGramTokenFilterV2",
"name": "NGramTokenFilter",
"minGram": 3,
"maxGram": 8
}
],
I came upon Suggesters and was wondering what the pros/cons were between these 2 approaches.
Basically, I'm doing an JavaScript autocomplete text box. I need to do partial text search inside of the search text (i.e. search=ell would match on "Hello World".
Azure Search offers two features to enable this depending on the experience you want to give to your users:
- Suggestions: https://learn.microsoft.com/en-us/rest/api/searchservice/suggestions
- Autocomplete: https://learn.microsoft.com/en-us/rest/api/searchservice/autocomplete
Suggestions will return a list of matching documents even with incomplete query terms, and you are right that it can be reproduced with a custom analyzer that uses ngrams. It's just a simpler way to accomplish that (since we took care of setting up the analyzer for you).
Autocomplete is very similar, but instead of returning matching documents, it will simply return a list of completed "terms" that match the incomplete term in your query. This will make sure terms are not duplicated in the autocomplete list (which can happen when using the suggestions API, since as I mentioned above, suggestions return matching documents, rather than a list of terms).
Below I have environment file and recipe can you explain I am not getting what is the list here.
{
"json_class": "Chef::Environment",
"description": "prod environment",
"default_attributes": {
},
"chef_type": "environment",
"override_attributes": {
"user": {
"mapr": {
"id": "application",
"group": "application",
},
"local" : {
"id": "chef",
"group": "chef"
},
"ldap" : {
"id": "ldap",
"sudo": true,
},
}
"name": "prod"
}
Below is the recipe what is the list here i did not get
node['user_create'].each do |list, user|
group user['group'] do
group_name user['group']
gid user['gid']
action [:create]
ignore_failure true
end
user user do
username user['id']
uid user['uid']
group user['gid']
home user['home']
manage_home true
end
if list !='ldap'
How list is passing here in if condition
You are not actually passing in any attributes via the environment, which you can see because the values of default_attributes and override_attributes are both just empty hashes { }. The data you've included there is just ignored by Chef as noise. In the future I recommend you use the Ruby DSL for environment files as it has more error checking for things like this (though not perfect error checking).
As an aside, you've been asking a lot of questions on here and seem to be struggling with Chef. Please consider joining the Chef community Slack team and asking there instead as it's a full chat system and thus the community could offer real-time help rather than here random blurbs.