I have a composite entity working fine. But when I try to change its value by another composition in fulfillment, it's been interpreted as a string value:
const entity = {
"name":"projects/myproject/agent/sessions/" + sessionID +
"/entityTypes/lia_parametro1",
"entities":[{
"value":"#sys.email:email",
"synonyms":[
"#sys.email:email"
]
},
When I put this value directly in Dialogflow Console(#sys.email:email) it works fine, but when I try to do this dynamically as above, it understands "#sys.email:email" as a value, instead of a System Entity.
Is there a special way to declare System Entities in Json format?
Many thanks for any tip!
Diego Mesquita
I think you're getting confused about what the purpose of entities are.
Entities are used when extracting parameters - they're hints to Dialogflow to say "I'm trying to grab a piece of data from whatever the user has said, by the way the piece of data I want you to extract looks like this -> [the values of #sys.email]".
When something reaches your fulfillment code, that whole data extraction process has been done, and therefore entities become irrelevant. You can run whatever code you wish to extract data (for example a regex), then assign that as a parameter value to some output context.
To quote the documentation:
Each intent parameter has a type, called the entity type, which dictates exactly how data from an end-user expression is extracted.
I hope this helps - if not, can you give a little more info about your use-case?
Related
Since #sys.airport only exists for the default English locale, I want to create a custom entity that emulates it for other locales.
From what I've read here, you can put subentity types into the value fields, say, the system entity #sys.geo-city:city and a custom entity #usr.iata-code:iata, and it will match either one or the other.
But I don't understand how you would tell Dialogflow which city and which IATA code go together, so that Dialogflow (ES) would know to send the complete object {"city":"Amsterdam", "iata": "AMS"} to the webhook after matching either "Amsterdam" or "AMS", as it does happen with #sys.airport.
Thanks for any input!
It will be difficult to create a custom entity that works just like #sys.airport. The #sys entities are special and can do somethings custom entities can't, for instance, pairing values together.
As you pointed out, you can put multiple entities together in one single entity by using Composite Entities, but the only thing this does is allow you to recognize two values made up from other #sys or custom entities in a single entity. It doesn't give you the option to create pairs between the values of the entities.
If you would want to create something like this, you would need some code that does a look up in a dictionary or list. So when "AMS" is matched, the code fills in the missing property "Amsterdam" or vice versa.
I have an issue developing an agent with dialogflow (api.ai). I am using a lot of entity values which are all different from one another. however there are similar synonyms for some entity values but the agent is returning only one value.
How can i get all the possible matches or ask question to resolve the ambiguity
for example i have an intent like: tell me the location of ABC express train
if my entity values are :
entity synonym
15127 ABC express
12345 ABC express
I want it to return two values or ask question to resolve such ambiguity
how can i work this out
Thanks in advance
If you enable fulfillment for this intent, you can take a look at the value the user said and ask a further question if you need to disambiguate between entities.
Let's imagine you are extracting an entity called "trains". The parameters table in your intent might look like this:
By default, if the user says ABC express, the fulfillment webhook will be called with the following parameter hash:
"parameters": {
"trains": "15127"
}
This isn't enough information to decide if the request was ambiguous, since train 15127 might also have non-ambiguous synonyms.
You can configure Dialogflow to send the original text of the entity, alongside the resolved value. This means you will receive the following information to your webhook:
"parameters": {
"trains": "15127",
"original": "ABC express"
}
You can then use some simple logic to ask a further question if the value of original appears in a list of known ambiguous synonyms.
To have Dialogflow send this data, modify your parameters table so it looks like the following:
This will cause the original synonym to be sent to Dialogflow alongside the resolved value.
According to the help pop up:
ID
This field's value represents the script ID, used to identify this
record for scripting purposes. It is a text field.
Internal ID
This field's value is a read-only system-generated unique identifier.
It is an integer field.
Both fields seem to uniquely identity a record type.
One is a string, one a integer.
The string ID is used for searches and
loading of records, but I've also seen Internal ID used when
referring to a record type from a lists point of view.
Can anyone provide the reasoning behind having two identifiers and when to use one versus the other when scripting?
The major difference is that you (as the creator of a custom record or script) are in complete control of the text ID. You can establish patterns and best practices for defining these IDs, and it will make it very easy for developers to identify record types just by looking at the string ID. You have no control over the numeric ID. When looking at code, it is much easier for me to determine what records I am referring to if it looks like:
nlapiSearchRecord('customrecord_product', null, filters, columns);
nlapiResolveURL('SUITELET', 'customscript_sl_orderservice', 'customdeploy_sl_orderservice')
as opposed to looking at:
nlapiSearchRecord(118, null, filters, columns);
nlapiResolveURL('SUITELET', 13, 1)
I'm not even sure the second nlapiSearchRecord actually works, but I know that nlapiResolveURL can be written that way.
That said, if you simply let NetSuite generate the text ID, you'll end up with generic IDs like customrecord1, which I find no more useful than the numeric ID. It is a good practice to explicitly specify your own IDs.
Furthermore, the numeric ID can vary between environments (e.g. Sandbox could be different than Production, until a subsequent refresh occurs). If you are following good migration practices, then the text ID should never vary between environments, so your code would not have to make any kind of decision on which ID to use based on environment.
Rarely have I found myself referencing any record, whether native or custom, by its numeric ID; scripts are always using the text ID to reference a record type.
I'm developing an application with Domain Drive Design approach. in a special case I have to retrieve the list of value objects of an aggregate and present them. to do that I've created a read only repository like this:
public interface IBlogTagReadOnlyRepository : IReadOnlyRepository<BlogTag, string>
{
IEnumerable<BlogTag> GetAllBlogTagsQuery(string tagName);
}
BlogTag is a value object in Blog aggregate, now it works fine but when I think about this way of handling and the future of the project, my concerns grow! it's not a good idea to create a separate read only repository for every value object included in those cases, is it?
anybody knows a better solution?
You should not keep value objects in their own repository since only aggregate roots belong there. Instead you should review your domain model carefully.
If you need to keep track of value objects spanning multiple aggregates, then maybe they belong to another aggregate (e.g. a tag cloud) that could even serve as sort of a factory for the tags.
This doesn't mean you don't need a BlogTag value object in your Blog aggregate. A value object in one aggregate could be an entity in another or even an aggregate root by itself.
Maybe you should take a look at this question. It addresses a similar problem.
I think you just need a query service as this method serves the user interface, it's just for presentation (reporting), do something like..
public IEnumerable<BlogTagViewModel> GetDistinctListOfBlogTagsForPublishedPosts()
{
var tags = new List<BlogTagViewModel>();
// Go to database and run query
// transform to collection of BlogTagViewModel
return tags;
}
This code would be at the application layer level not the domain layer.
And notice the language I use in the method name, it makes it a bit more explicit and tells people using the query exactly what the method does (if this is your intent - I am guessing a little, but hopefully you get what I mean).
Cheers
Scott
In a JSF page I have to display the data from an entity.
This entity has some int fields which cannot be displayed directly but need to be translated into a descriptive string.
Between them some can have a limited number of values, others have lots of possible values (such as a wordlwide Country_ID) and deserve a table on the Db with the association (ID, description).
This latter case can easily be solved navigating via relationship from the original entity to the entity corresponding to the dictionary table (ID, description) but I don't want to introduce new entities just to solve translations form ID to description.
Besides another integer field has special needs: the hundred thousand number should be changed with a letter according to a rule such as 100015 -> A00015, 301023 -> C01023.
Initially I put the translation code inside the entity itself but I know the great limits and drawbacks of this solution.
Then I created a singletone (EntityTranslator) with all the methods to translate the different fields. For cases where the field values are a lot I put them inside a table which is loaded from the singletone and transformed in a TreeMap, otherwise the descriptions are in arrays inside the class.
In the ManagedBean I wrote a getter for EntityTranslator and inside the jsf I use quite long el statements like the following:
#{myManagedBean.entityTranslator.translateCountryID(myManagedBean.selectedEntity.countryID)}
I think the problem is quite general and I'm looking for a standard way to solve it but, as already stated, I don't want to create new 'stupid' entities only to associate an ID to a description, I think it is overkill.
Another possibility is the use of converters Object(Integer) <-> String but I'm more comfortable in having all the translation needs for an Entity inside the same class.
Your question boils down to the following simple line:
How can I display a field different from id of my entity in my view and how can I morph an integer field into something more meaningful.
The answer is that it depends on a situation.
If you solely want to input/output data, you don't need id at all apart from the possible view parameter like ?id=12345. In this case you can input/output anything you want in your view: the id is always there.
If you want to create a new entity most possibly you have a way of generating ids via JPA, or database, or elsehow besides the direct input from the user. In this situation you don't need to mess with ids as well.
If you want to use information on other entities like show user a dropdown box with e.g. a list of countries, you always have the option to separate label (let it be name) and value (let it be id), or even have a unique not null column containing the country name in your database table that will serve as a natural identifier. If you'd like to get data from the user using an input text field you always can create a converter that will do the job of transforming user input strings to actual entity objects.
Regarding the transformation of your integers, you've actually got several choices: the first one is to attach a converter for these fields that will roughly do 301023 -> C01023 and C01023 -> 301023 transformations, the second one is to write a custom EL function and the third one is to prepare the right model beforehand / do the transformations on-the-fly.