Heya folks so I'm working on a LUIS bot and I've run into a bit of confusion regarding how entities work.
So I have this LUIS app set up with a single Entity and a single Intent. This Entity, called Alert, has three children, each of which is an Alert Type. The Intent, called AddAlert, has one Action Parameter: AlertType. This Parameter is supposed to be required, so I checked that box. The Parameter's type is Alert (the parent Entity), and its Prompt is, "What kind of alert?"
So a chat with this app should go like this:
"Add an [insert Alert type here] alert."
Or...
"Add an alert."
Whereupon the Prompt should be triggered.
The problem I'm having, though, is that the Prompt is always triggered. So LUIS is obviously recognising the keywords for the Intent, but it's not making the association for the Entity types necessary to fulfill the required Parameter. When training LUIS, I assigned the children Entity types to the words associated with them, and I figured that using the parent as the required Entity would allow any child to fulfill the requirement. Is that not the case? I tried finding more information on this matter but came up short. I suppose I could make the Parameter not required, but that would complicate things quite a bit. Moreover, I need to be able to differentiate between the three Alert types. Is there something I'm missing? Can I require any single child of an Entity and not every single child?
For reference, here's the Intent's info:
Any help or information would be appreciated!
All righty so this is pretty funny. LUIS has been completely revamped such that all that action business doesn't exist any more. Thus, this question is now kind of irrelevant. Yay?
Related
I have a customer requirement that necessitates a conditionally prompt from Alexa. Basically, the user will ask {intent} {utterance}, the back-end will check their account to see if they have more than one item in a list; if so, it will ask "which one item 1 or item 2". They will need to respond with 1 or 2.
If there is only one item in their list, it will default to that item and not require input from the user.
My understanding of how multi-turn dialogs works is that I must create a dialog model with at least one required slot. As you can see in my example, there isn't always a required slot.
Is this possible? If so, can you outline (at a high-level of course) what steps I should take?
Note: Unfortunately, one of the requirements is that the endpoints be handled in Azure; therefore, I must utilize Alexa.NET instead of the typical SDKs. Not sure if that changes anything.
Dialog handling
Yes it's possible.
After your:
ask {intent} {utterance}
it will hit your backend with dialogState STARTED
now you can check if you have multiple items
yes(multiple items): delegate dialoge handling back to alexa and alexa will ask for the slot number. You now check if dialogState = COMPLETED and so on
no (only one item): just respond back to the user without dialog delegation
SDK
It does not make a difference with Alexa.NET if dialog handling is implemented there. I also struggle sometimes to find examples for the Java SDK ;-).
Here is a video which helped me.
I have an "inbox/messaging" structure that I'm working on, that allows for multiple kinds of parents. As in, people can leave comments on a few different kinds of objects. For this example, let's say someone is leaving a comment on a Article object.
The way we've formatted our data, the comment is created as a Message object, and that object is a child of Article (and Article is a child of Account). So when we query for the list of messages, we simply ask for all Messages that are children of that instance of Article. That looks like this:
Message.query(ancestor=source_key)
source_key here is the Key of the article we're viewing.
Great, this works really well and is pretty fast.
Now we want to add replies to those Message objects. I figure we'll just store replies the same way we add Messages to Articles. Which is to say, a Reply is simply another instance of Message, and the parent of that reply object is the message it's replying to. So basically, instead of leaving a comment on an Article, you're leaving a comment on a Message.
This sounds good on paper but it seems that in practice, the Key it ends up getting is structured like so:
Key('Account', 5629499534213120, 'Article', 5946158883012608, 'Message', 6509108836433920)
Which turns out, when we query for the list of messages, it return the replies as well in the response, as if they aren't replies at all.
Some questions:
Is there any way we can do like a "shallow" query? To strictly get only the immediate children of that Article?
I've read more on how ancestor queries work and because ancestor queries have a 1 write per second limitation, I'm now wondering if it may be better to change how we store this to where a Message is not the child of Article, and instead maybe have a KeyProperty of Article exist on Message, if that makes sense. And maybe no parent for Message. There could be lots of people leaving a comment on an article, or also lots of people leaving replies to those comments. But even so, Article is a child of Account too, along with a lot of other kinds of objects, and generally we don't run into any issues with lots of different writes. So would we even run into this write limitation?
EDIT: I've moved on a little bit and am trying to query only replies for a given message, so I'm looking for all messages that have a parent (ancestor) of another message.
So given this key as the ancestor: Key('Account', 5629499534213120, 'Article', 5946158883012608, 'Message', 5663034638860288)
I query our message table, and I get back that exact same key (as well as other messages). How is that possible? If I'm specifying an ancestor, in what world does it make sense that I would get back the same object I'm using to query the ancestor with? The parent of that message is just:
Key('Account', 5629499534213120, 'Article', 5946158883012608)
So, obviously the ancestor doesn't strictly match there. Why would my query return it then? Hastebin of what, basically, I'm running into: https://hastebin.com/karojolisi.py
Regarding the question on write limitation, if you are using the Cloud Firestore in Datastore mode, then the limitation of 1 write per second is by entity and not entity group.
See https://cloud.google.com/datastore/docs/firestore-or-datastore
"Writes to an entity group are no longer limited to 1 per second."
and https://cloud.google.com/datastore/docs/concepts/limits
"Maximum write rate to an entity" is "1 per sec"
So, irrespective of which approach you take, with datastore mode, writes shouldn't be a concern as the messages and replies are not expected to be edited. Unless of course, if you have any kind of aggregate information like the number of replies for a given message which require updating the parent message record with each child record.
Regarding your main question of querying only the messages for an article and not their replies, one option is to have a field called article_id and populate this only for the top level messages and have this also in the index (prefix of the ancestor composite index). The reason to recommend article_id and not a boolean is, since this field is indexed, it is better to have the field not be based on a narrow range of values.
The reason to prefer this approach to storing the messages in a separate table is that all messages belonging to an article will be stored close by with the initial approach and that is better for read performance.
I will preface that this may not be the best use of a branch template, but it seems ok on paper, with a few drawbacks.
Sitecore 8, we have a Template called "Program." Program needs the ability to either be a two-column (9-3 grid) or a full (12-col grid). These basically represent a full version and a version with a right rail.
We want the content editors to be able to decide when they create the page whether they want a "program" or "program with right rail." To set this up, we created two branch templates. One that looks like this:
Layout: Base Layout
Renderings: Full (sublayout), Program Detail (rendering, dropped onto Full's placeholder)
And one that looks like this:
Layout: Base Layout
Renderings: Two-Column (sublayout), Program Detail (rendering, dropped onto Two-Column's placeholder)
Placeholder settings: Right Rail (allows right rail components to be added)
Then when the user right clicks on the "programs" item in the tree, they can pick one of the two options above and it creates the program item with the appropriate presentation details (again, either a full width or a two-col).
This all works, but the problem is if I ever have to change something on one of the branch templates, that change is not propagated to any items that were created based off of that branch like standard values works. There's no "branch delta" that I'm aware of.
Is there a better way to handle this? In my head, it essentially sounds like I need standard values for a branch template, but I don't think that exists.
Another thought I had was to create an "Program Master" template and then create two templates that inherit from it, Program and Program with Rail. That way they would share the same data but would have different standard values and allow me to set different presentation details for it. This feels a little dirty since I'd basically be creating a template to handle look and feel. I hope I'm explaining this correctly, but if not I'll update with more info if I'm being unclear.
Unfortunately if you want to take advantage of "layout deltas," out of the box you would need to have a separate template with its own standard values, as far as I'm aware.
You could probably do something fancy with the renderLayout pipeline if you wanted -- e.g. Sitecore Zen Garden introduces the concept of "Designs" which are used to define default layout, and allow you to separate layout from Standard Values. But you're going off the reservation at that point.
I've got 2 applications (lets call them AppA and AppB) communicating with each other.
AppA is sending objects to AppB.
There could be different objects and AppB does not support every object.
An object could be a Model (think of a game, where models are vehicles, houses, persons etc).
There could be different AppBs. Each supporting another base of objects.
E.g. there could be an AppB which just supports vehicle-models. Another AppB just supports specific airplane-models.
The current case is the following:
There is a BasicModel which has a position and an orientation.
If another user wants extra attributes, he inherits an ExpandedModel. And adds e.g. an attribute Color.
Now every user who needs additional attributes inherits from a more general model. After a while there is a VehicleModel which could activate windshield-wipers, an AircraftModel which could have landing lights or a PersonModel which could wave goodbye when a certain boolean is set to true.
The AppB always needs to be customized if it should support a new Model.
This approach has a big disadvantage: It's getting extremely complex after a few inheritations. Perhaps there are redundancies like an ExpandedAircraftModel which could use windschield-wipers too.
Another approach:
I create just one Model-class which has an attribute-list. The most easy implementation would be a std::map where the Key is the attribute-name and the Value is the attribute-value.
The user could now enter as much information as he wants. If he wants to use a windshieldwiper he just adds a "windshieldwiper - ON"-pair.
If AppB supports windshieldwipers it just looks if there is such an attribute in the list and reads the related value.
A developer of AppB needs to document well what attributes he supports. Every developer has to check if the specific attribute is already existing and how it is called (e.g. one developer could name his attribute windshieldwiper and another calls it windshield-wiper)
This could get extremely complex too and the only thing a user can relate to is the documentation or a specific standard-specification which has to be kept at a central space.
Finally, the question:
Which approach is better?
Did you see any additional disadvantages?
Is there a third approach which should be used instead of these two?
Just for a comparison, Google's Protocol Buffers uses a combination of both but leans hard toward your second example.
If you have distinctly different data that needs to be sent over the channel, you use the tool to generate a derivitive of the "message" class, but each message can contain other messages, and you can nest message definitions in themselves. When a message is sent out, the receiver checks the fields to determine what type of message it is and what fields are contained within.
The downside is that your code becomes overly verbose very quickly, as you can't really use inheritance to automate the process of acting on an incoming message, but the upside is that your protocol messages stay highly organized and easy to DEBUG since you're using a reflexive attribute list of sorts.
Im looking to build a topic map to catagorize content.
For example the Topic 'Art' may have sub categories of 'Art History', 'Painting', 'Sculpture' etc etc.
I've crawled a few online resources, but I've hit a problem related to how I wish to use the hierarchy.
I've got a lot of content that I wish to index by topic. So to give the above example, if a user searches for 'Art' then they will not only get anything that mentions 'Art', but also anything that mentions 'Painting', even if it doesnt mention 'Art'. Fair enough.
But if, in another part of my heirarchy, I have 'House Maintenance', for example, then that might also have a subtopic of 'Painting'.
But then if a user searches for 'Art', my engine will say 'well, Painting is a sub category of 'Art', so I'll include this peice of content thats all about the best colour to paint your bathroom walls....
Has anyone come across this problem before? I've tried googling, but without knowing the exact terminology its hard to make headway....
EDIT: More succinctly, 'Painting' is a subtopic of 'Art', but if something is about 'Painting' then it doesnt neecssarily follow that its about 'Art', since 'Art' is not the only parent of 'Painting'.
In "topic maps", as it is understood in the related standard you can set different "scopes" to a topic. So "painting" may be part of two scopes, with different meanings.
A topic map:
http://www.ontopia.net/page.jsp?id=vizigator
Scope:
http://www.ontopia.net/topicmaps/materials/tao.html#stp-scope
If the Topic Map you are creating is built on Topic Maps technology, then subjectIdentifiers can be used to distinguish between two Topics with the same name (both named "Painting") that actually represent two different Subjects (Painting as an Art form, and Painting in the sense of home renovation).
If someone queries about Art and you drill down to Painting, then you can return only those entries related to 'Painting as an Art form' because those Painting entries are no longer thrown together on one heap.
Turning up late to this party (you've probably already built it or moved on or found an answer) but thought I'd throw in my 2 cents having worked on a high end Topic Map based CMS.
What you are missing out in your description is how topics are linked together. Topic are linked together via Associations that in themselves have Type's and Roles. So yes painting would be a child of art and of house maintenance but they would be linked differently.
Defining your type and role is up to you really, there is no hard and fast rules its really just down to your own leanings. So
Topic: Art
Association: Source=Art, Reference=Painitng, Type=Culture, Role=Practice
Topic: House Maintenance
Association: Soruce=House Maintenance, Reference=Painting, Type=DIY, Role=Activity
I suck at categorisation but hopefully you can see what I'm getting at. You'd filter your searches based on the type and role. So if someone searched for art you'd return painting and if you wanted to dig deeper and return co-related topics you are talking about returning Culture associated topics and not DIY associated topics.
Topic Maps if done right are extremely flexible, you've also got scope and language baked in too if you do it right. You should be able to link the same topics together in a 100 different ways and see the data differently depending on your starting point.
Information Architecture for the World Wide Web would give you a good start on organizing information... it's a good read, but might not be so technically detailed.
Since you want to process House/Painting and Art/Painting differently, then it seems like you'll need two distinct entries for Painting (one for each meaning). Which one you associate a given 'lump of text' with could be based on context clues from the text itself, if your text processor is powerful enough.
For example, whenever you have a conflict like this, look in the text - do you see other words there? Like 'sink', 'wall', 'hard wood', or 'windows'? Or do you see other terms like 'Monet', 'impressionism', 'canvas', and 'gallery'? That'll allow you to automate the decision, and should be fairly accurate. The only snag is that this presumes you have a fairly healthy dictionary of 'related terms' lying around somewhere.
On the user-end, when Painting is selected, you'd simply have to either merge all the results together, or present the user an option to select which parent topic they want to be viewing results from.
I don't know of a specific name for that, but I don't think it should really be a problem, either. All it calls for is that Art/Painting and House Maintenance/Painting are understood as separate entities. Someone searching for "art" gets subcategories of Art, so gets Art/Painting. Someone searching for "house maintenance" gets subcategories of House Maintenance, so gets House Maintenance/Painting. Someone searching for "painting" gets Art/Painting and House Maintenance/Painting, which is appropriate.