I try to understand the logic behind the weather bot in the wit.ai quick-start.The story is build with a trait intent (supposed to be something like "what is the weather ?") and an entity is declared to get where the weather is wondered. So, I would think this story is only triggered when weather is asked AND location is given.
This is not the case since the illustration of jump / bookmarks just below this first step deals with unset location.
Hence my question : how does Wit.ai decide which story to trigger ?
Actually, there is no difference between :
What is the weather in Barcelona ? and What is the weather ?
from a decision regarding the next action to choose from the Wit engine standpoint.
Previous contexts and current context (and contained key) are what matters for this task.
As the quick-start puts it:
Only trait entities have their value influence the prediction. For
non-trait entities, the value is ignored with regards to action
prediction.
My advice on this is to create a flushContext action which returns an empty context and to trigger it everytime a give story comes to an end.
Related
I need a help about distinguish similar entities.
In my case I have one entity called '#agent' with some entries, two of them is 'Iago Campos' and 'Iago Coutinho'. I have an intent called 'transfer' that is triggered when user says that want to talk to someone. When user says 'I want to talk with Iago' dialogflow doesn't match any of the 'Iago'
I want to know if it's possible to make dialogflow ask to user if he wants to talk with Iago Campos or Iago Coutinho. I was looking aboult Fulfillment, but for many reasons I'm not confortable using webhook to just distinguish agents...
#Agents entries
Dialog Flow doesn't match any of the “lago” because it does not know what decision it has to take since it found 2 matches “lago Campos” and “lago Coutinho”.
If you proceed to say “Campos” dialog flow will find only one match “lago campos” and it will return it. It would be ideal to remove the world “lago” since it causes redundancy in your system.
On the other hand a fast solution would be to create another Intent specifically for when the user enters the word “lago” and that it is linked with a trigger that replies what “Lago” is it referring to. Here the final user can choose one “lago” or another.
So here I could suggest creating this behavior using a Fulfillment webhook in that way you can use it from the same intent
For the first i want to sorry for my english. I'm learning domain driven design and trying to implement some concepts in an application i'm working on. My task is not so complex to fully implement DDD on all the levels but i really like it's principles and the core idea and try to use it.
Lets say app is selling books. So i have a Book entity and BooksCollection or BooksRepository. I'm working on frontend and that collection or updates to it is coming from server. And i want to represent it on BooksScreen in BooksList which consists of BookCard. Press on that card for the first calls something like selectBook which changes the selectedBookId in collection and for the second navigates user to BookDetails screen where the data of selected book is represented and the user can do some actions related to domain logic.
The first question is where do i put the loading state of that BooksCollection and according actions to change it ? Loading state is not a domain logic as i understand, it's not an entity status like "todo done" or something. But i need to show a loading indicator in the UI list when the collection updates, error for loading error and success respectively.
And the second is where do i put the the same loading state for single Book ?
I separate it cause for collection i may store that state in some application related class e.g. "BooksScreenState" or something with less stupid name. But what if i decide to show state for each specific card in the UI e.g. that specific card failed to load. Or i have a single User in app and his data can be loading, he can be authorized or not et cetera.
So i can summarize that to something like "how to connect domain and application logic to present a UI".
An interesting question. I don't usually think to apply DDD to the UI level because for the most part, the UI isn't full of business rules and also because I mostly use reactjs and UI frameworks are usually very prescriptive and don't allow much in the way of flexibility.
To answer your question though: If you did want to get a "loading" status in your UI (that's designed using DDD), it'd have to be attached to a "View" object or some representation of the "view"; because that fits the UL (ubiquitous language) better. Think of how you have described it in a little snippet of your question:
But what if i decide to show state for each specific card in the UI
That means your card is an object (entity or value object) that has a enumerable state of loading, loaded, error. You can queue on that object in your UI to display a desired representation of that field.
So, both your questions have essentially the same answer. Since you are loading the UI, your state is only relevant to UI objects and not entities that are in the domain model like "Books" that are represented in the backend. Even if you had a front-end representation of "Books" - like in javascript for example - having a loading state still makes more sense in the view object in the view layer.
Note that there's some simplification/flexibility to this answer because it's also valid for your design to have a View that's an aggregate that contains a Books. Those Book objects could have a "loading" state on them. All of this is still restricted to the UI layer though and such an aggregate and it's specific design will depend on the flexibility your UI-framework allows.
Let's say I create a story dedicated to giving the weather in a given place, and a story dedicated to listing the possible activities in a given place, and a allowing to buy tickets for them.
Let's say a user launches the second story by entering "what can I do in Paris ?". Bot answers with a list of things and asks the user to input the one he'd like to buy a ticket for.
But, instead of entering a number, the user inputs "What is the current weather in Paris ?". Will the first story be triggered ?
A wit.ai blog post states :
We strengthened the initial overfitting: when a user follows the
scenario of a story, the bot will 100% stick to the story.
Should we repost the intent as a context key so that the next action prediction scope stays within the same story ? Should all end of a story flush the context of all keys (which in our tests seems to be a very good idea not to stick to a story) ?
Thanks for any insights.
I have a User that wants to see his online profile, in a site where he previously has registered at. I am in charge of making a Dataflow Diagram out of this situation. I know for sure that the System will return a Profile. That is why I put an arrow from System to User.
How can I express that the User is requesting his profile to the System? I can't think of a way of expressing that in a DFD. I guess it's maybe because you are only supposed to show data flow in a DFD and not actions/requests? Should I completly erase the arrow that goes from User to System(?See his profile?) ?
Context Diagram (Level 0 Dataflow Diagram)
Level 1 Dataflow Diagram
Thanks
No hard and fast answer to this. It's possible to argue against including it (could be considered a control flow, not a dataflow). However, assuming purpose of DFD is for human understanding (i.e. it's a picture to look at) go with what makes most sense to your audience.
If I were drawing it, I'd include the input flow on both L0 & L1 (probably named View Profile rather than Check his profile - I prefer imperative statements). It's both the event that triggers action, and will also likely carry data to identify the user.
I wouldn't however include the flow marked ??? on the L1 diagram. Reason: you're pulling data from a datastore so the query is implicit.
hth.
Struggling with a decision on how best to handle Client-level authentication with the following model hierarchy:
Client -> Store -> Product (Staff, EquipmentItem, etc.)
...where Client hasMany Stores, Store hasMany Products(hasMany Staff, hasMany EquipmentItem, etc.)
I've set up a HABTM relationship between User and Client, which is straightforward and accessible through the Auth session or a static method on the User model if necessary (see afterFind description below).
Right now, I'm waffling between evaluating the results in each model's afterFind callback, checking for relationship to Client based on the model I'm querying against the Clients that the current User is a member of. i.e. if the current model is Client, check the id; if the current model is a Store, check Store.clientid, and finally if Product, get parent Store from Item.storeid and check Store.clientid accordingly.
However, to keep in line with proper MVC, I return true or false from the afterFind, and then have to check the return from the calling action -- this is ok, but I have no way I can think of to determine if the Model->find (or Model->read, etc.) is returning false because of invalid id in the find or because of Client permissions in the afterFind; it also means I'd have to modify every action as well.
The other method I've been playing with is to evaluate the request in app_controller.beforeFilter and by breaking down the request into controller/action/id, I can then query the appropriate model(s) and eval the fields against the Auth.User.clients array to determine whether User has access to the requested Client. This seems ok, but doesn't leave me any way (afaik) to handle /controller/index -- it seems logical that the index results would reflect Client membership.
Flaws in both include a lengthy list of conditional "rules" I need to break down to determine where the current model/action/id is in the context of the client. All in all, both feel a little brittle and convoluted to me.
Is there a 3rd option I'm not looking at?
This sounds like a job for Cake ACL. It is a bit of a learning curve, but once you figure it out, this method is very powerful and flexible.
Cake's ACLs (Access Control Lists) allow you to match users to controllers down to the CRUD (Create Read Update Delete) level. Why use it?
1) The code is already there for you to use. The AuthComponent already has it built in.
2) It is powerful and integrated to allow you to control permissions every action in your site.
3) You will be able to find help from other cake developers who have already used it.
4) Once you get it setup the first time, it will be much easier and faster to implement full site permissions on any other application.
Here are a few links:
http://bakery.cakephp.org/articles/view/how-to-use-acl-in-1-2-x
http://book.cakephp.org/view/171/Access-Control-Lists
http://blog.jails.fr/cakephp/index.php?post/2007/08/15/AuthComponent-and-ACL
Or you could just google for CakePHP ACL