Watson assistant what entity should I use to capture a complaint/request text with no format(any text)? - ibm-cloud

I have a use case to capture Complaint/Request from user. How can i define an entity for handling these slots(subject of request, description of request). Here I cant use regex because these two slots can be any text, How can i define and capture the request.

If you want to capture a complaint or request, you need to design if it is allowed anytime or only after prompting the user.
If you know that the input is a complaint or request, I would recommend taking the full input and store or handle it as complaint text. Watson Assistant allows access to the entire input text. It also provides location information for detected entities. If you define certain keywords, e.g. for specific complaint categories, the entity would be detected and could serve for tagging the complaint or filing it along with categories.

Why not create Entity as Complaint/Request and through a Skill pass the response from NodeMailer as an Email. It could we done through Skill's code. So user input be like My Complaint is () or Request is ().
And through Slots we can ask user for his Email address having 1 more entity as "Email" from where WA team can connect him.

Related

Rest API Hateoas : Should API response have identifiers as hard coded or as placeholders?

Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.

FB Chatbot how to get the previous message

Is it possible to receive the previous message that the user have send to the chatbot (without using quick replies or postback buttons). Example:
User: "Can you call a friend?"
Bot: "Who should I call?"
User: "Tim"
In the API I now have just the information "Tim", without knowing if I should call him or text him or make him a sandwich or whatever. So I basically I want to add some Postbackdata or metadata additionally to the text "Can you call a friend" (intent: 'CALL'), so the message "Tim" will come with that data.
Is there a way without storing the data into a database? AWS Lambda with ClaudiaJs.
I found the metadata field in the FB API which turns out to be the wrong field for that since it is only for communicating between several apps?!
What you are looking for a called a "slot-based bot", or slot-filling, basically meaning that you have a "slot", or blank that needs to be filled in before your bot can perform an action. In your example you have two slots: action and person
Actions could be: call, text, message
Person: name of a person, friend, etc.
I don't think any of the message frameworks (Slack, Facebook, etc) will provide you with the information you need. You will need to build this logic out yourself.
You can look at using wit.ai stories to achieve this.
Look to this similar Stack Overflow question and answer.
You can reverse order of conversation, and at beginning user writes some text or send you something else. After receiving, you should send to user buttonsTemplate, where postbacks will be like "CallTo&Tim" where instead of Tim you can put every text you need to pass to next executor(and you also can store previous user message here). Than just make substring of postback, check it`s type and do whatever you want.

How to identify two legs of a sip call?

I am developing a sip call tracking application. I have used Tag ID fields to connect the two call legs
of a call. But some times tag ids will not be same.
What i have done is -
The tag ids are associated to a corresponding Call ID.
Is there any other field i need to consider for identifying legs(dialogues) of a call.
The above one is an exmple for 1 call with tag ids. Different colors used for two legs. And the only similarity i have got a number 3568450037 in tag id's. 10.10.10.120 is the server ip.
I have to find strong connection between the call legs. Please help me...
And please suggest me some links to solve this issue..
thank u...
The Call-ID, From tag and To tag are all that's used to identify a dialog. From the SIP RFC chapter on Dialogs. The only trick is matching up local and remote tags, i.e. the To header tag at one end of the call matches the From header tag at the other end of the call and vice-versa.
A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA. The
tags are opaque tokens that facilitate the generation of unique
dialog IDs.
Update:
Following your edit with the table containing the IP addresses and tags there are two completely separate calls involved which each have their own dialog. I guess that your question was more along the lines of how to match two different dialogs from two separate calls rather than trying to match in-dialog transactions/requests.
There actually isn't anything in the SIP headers you can use to match two independent SIP dialogs to know that the calls have been bridged together. I assume you are working with a B2BUA since it's the only common SIP element that bridges calls. One way to match the dialogs is to look into the SDP carried in the INVITE requests and responses. At the very least you can get the port number each leg is sending and receiving on and match them that way.
A bit late of an answer, but in case it helps anybody else:
If you are the one writing the B2BUA application you can modify it to add a header to the messages on each leg with the same identifier, then that identifier identifies not just one leg but the whole call.
There is an informational IETF document that proposed just that:
https://datatracker.ietf.org/doc/html/draft-kaplan-dispatch-session-id-03

Post/Redirect/Get pattern for HTTP Responses with application/excel MIME Type

I want to post some data to the server, and in response, I want to create a CSV file, with application/excel as the MIME Type (recently recognized as Internet Media Type), to force the browser to open the generated CSV file in Microsoft Excel. However, I also want to prevent user from re-submitting the same info (re-posting the form) by any accident as the result of refreshing the page.
With simple CRUD operations, I use Post/Redirect/Get pattern, so that any further refreshing will only send HTTP Get Request to the server, without any parameter, thus not changing server's state (Idempotence).
What is the recognized pattern for stopping user from re-submitting (re-posting) the same info to the server, when the response is not a page, but a file?
Any idea?
The Post/Redirect/Get pattern is an answer to a browsing event.
Here, there is no browsing action (the form submission only open a 3rd party app, i.e excel), and so any kind of browsing related pattern will be useless.
I suggest you use both a server side trace of the initial submission (with a unique token maybe), so you can prevent the file generation, and an easy to write client side script like <form onsubmit="this.onsubmit = function(){ return false ; }">
I can offer you one other solution.
Take hash (MD5/SHA256 ..) of your submitted data. The hash will be [fairly] unique.
Put it in list in a session with a time limit, say 5 minutes.
Even your user submit same data. Hash will be same and you can give error message to your user.
If different users can post same data, you can also hold user information in the list. And give error message according to user.

Drupal email users

I'm using Drupal 6.16: When a user creates an account on my site I have them select a category (ie children, youth, adult, etc). This is done with the select list box using the content_profile module. I have a content type that posts an announcement. In this content type is a check box that says 'email group'. Right now it does nothing, but what I would like for it to do is e-mail all the users that are associated with the group they chose when signing up for their account. If this will require extra code please be specific as I am not a strong php programmer.
Thanks for the help!!
msindle
There might be some module that do it exactly, but I don't think so.
I would have done it using few building blocks:
Retrieve the list of emails using Views - define a view that gives you the addresses according to a given group argument.
Use Rules module that will send an email notification after node is created.
Combine the two (this is the hard part) - insert the values from the view as the recipients for the email. You might be able to do it using PHP inside the Rule definition, plus view execution.
Try to accomplish it, and if you get into troubles, you are welcome to contact me via shushu.i#gmail.com
I would try http://drupal.org/project/subscriptions module + http://drupal.org/project/messaging module. You can set preferences for automatic subscribing to content type. Maybe Rules module can subscribe users automatically after creating or updating content_profile. Or maybe Rules can flag users after creating or updating content_profile and Subscription module could autosubscribe flagged users.