I followed what is described in the tutorial
I first added an Pattern.any entity
Next, I added a pattern for the required intent
I had already created an intent like shown and now I click on train
When I test, the intent is not hit
Any idea what's missing?
TL;DR: Read patterns doc and improve your entity detection.
The Issue
The problem with your example that you have posted here is that LUIS failing to actually detect command_paramsentity, therefore it cannot even match to your any one of those 3 patterns that you have shown.
As stated in Add common pattern template utterance formats to improve predictions:
In order for a pattern to be matched to an utterance, first the entities within the utterance have to match the entities in the template utterance. This means the entities have to have enough examples in example utterances with a high degree of prediction before patterns with entities are successful. However, the template doesn't help predict entities, only intents.
While patterns allow you to provide fewer example utterances, if the entities are not detected, the pattern does not match.
So you need to work on building out your command_params entity to make it detectable before using a pattern.
Your entity
I'm not convinced Pattern.any is the correct entity type for you to use, as it's an entity that's used for values that are of variable length--maybe they are extremely long, for example.
I don't know what type of values your entity can evaluate to, but I suspect it would probably be better to go the route of creating a simple entity + phrase list (uses machine-learning) or a list entity if the entity values are a known set (exact pattern matching), depending on your command params values.
Update: also there are regex entities as well, that may work for you. (Again, I don't know what your entity values could be, so it's hard to point exactly to the correct entity to use)
Additionally, if you need help with understanding how to improve entity detection in general, see this StackOverflow answer.
The patterns are extremely literal. If the part of the phrase does not match exactly, the intent won't get recognized. (Note: you can add these phrases to the intent directly, instead of in the pattern, in which case it will recognize the intent but not the entities. Can be helpful if you have a dialog to prompt users for the missing entities.)
In your case, the way you have the pattern written you would need to write command create $mytest, which should recognize the intent as well as the entity mytest. Since you did not include the $ character in your test, neither the intent nor the entity was recognized.
You do have the ability to mark a character as optional via brackets [], though I've had mixed success with this. Your phrases are specific enough that it may work in your case. So instead you could make your patterns like command create [$]command_params where both command create $mytest and command create mytest would work and have the correct entity. Do note that if someone types something like command create $mytest please, it's going to pick up the entire phrase mytest please as your entity. (If anyone knows how to create a pattern that avoids this, that would be fantastic!).
Related
I am a trying to design a database to act as a language dictionary where each word is associated not only to its definition by also to its grammatical "taxon". E.g., it should look something like this:
"eat": verb.imperative
"eat": verb.present
"ate": verb.past
"he": pronoun.masculine.singular
"she": pronoun.feminine.singular
"heiress": noun.feminine.singular
"heirs": noun.masculine.plural
"therefore": adverb
"but": conjunction
It seems that a natural data structure to hold such a grammatical "taxonomy" should be some kind of tree or graph. Although I haven't thought it through, I presume that should make it easier to perform queries of the type
plural OF masculine OF "heiress" -> "heirs"
At this point, however, I am just trying to come up with the least ineffective way to store such a dictionary in a regular relational database (namely a LibreOffice Base). What do you suggest the data schema should be like? Is there something more efficient than the brute force method where I'd have as many boolean columns as there are grammatical types and sub-types? E.g., "she" would be true for the columns pronoun, feminine, and singular, but false for all other column (verbs, adverb, conjunction, etc.)?
This is a really wide-open question, and there are many applications and much related research. Let me give some pointers based on software I have used.
One column would be the lexeme, for example "eat." A second column would give the part of speech, which in your data above would be a string or other identifier that shows whether it is a verb, pronoun, noun, adverb or conjunction.
It might make sense to create another table for verb information. For example, tense, aspect and mood might each be separate columns. But these columns would only make sense for verbs. For the nouns table, the columns would include number (singular, plural) and gender, and perhaps whether it is a count or mass noun. Pronouns would also include person (first, second or third person).
Do you plan to include every form of every word? For example, will this database store "eats" and "eating" as well as "jumps" and "jumping?" It is much more efficient to store rules like "-s" for present singular and "-ing" for progressive. Then if there are exceptions, for example "ate," it can be described as having the underlying form of "eat" + "-ed." This rule would go under the "eat" lexeme, and there would be no separate "ate" entry.
Also there are rules such as that plural changes words that end in y to -ies. This would go under the plural noun suffix ("-s"), not individual verbs.
With these things in mind, I offer a more specific answer to your question: No, I do not think this data is best described hierarchically, nor with a tree or graph, but rather analytically and relationally. LibreOffice Base would be a reasonable choice for a fairly simple project of this type, using macros to help with the processing.
So for:
"heiress" -> masculine plural = "heirs"
The first thing to do would be to analyze "heiress" as "heir" + feminine. Then compose the desired wordform by combining "heir" and "-s."
I was going to add a list of related software such as Python NLTK, but for one thing, the list of available software is nearly endless, and for another, software recommendations are off-topic for stackoverflow.
Trying to create a set of entities & intents for things of the ilk "describe <something>" or "tell me about <something>" or "list instances of <something>". The <something>s are not known in advance. Consequently, I cannot exhaustively list the possible values for the entity.
My impression from (albeit very little) use and from the documentation is that the conversation API isn't good at this type of thing. Experience thus far says that it will recognize things that match the examples given for some entity, but I haven't seen that it can generalize to something like
describe #target
show me instances of #target
without knowing the set of values for #target.
What am I missing?
Based on your example, you can combine the Intents and Entities for your purpose.
It's a good practice, I think.
Like Daniel said, you can create one intent with examples for asking about something, like these examples within your #describeAbout:
Describe about
Can you please describe
Can you please explain about
List instances of
etc...
And create one entity like #typesDescribe, with yours values. Like this values:
Paper
Love
Fruits
After Watson training your examples, with your Dialog, create one flow with the condition
if #describeAbout AND #typesDescribe:Paper
Response:
#typesDescribe (Will show the value: Paper) is a thin material produced by pressing together moist fibres of cellulose pulp derived from wood, rags or grasses, and drying them into flexible sheets.
And, usually, if your confidence about Intent and Entity are small, you can add one more condition for your Intent with the confidence level that you want. Check.
Obs.: You can create one Intent alone, with condition #describeAbout, and the response will ask for your user "You can know what?", and create one flow with various #typesDescribe:value, for example.
Which services are you talking about? NLC is able to do this, and so is Conversation, by using wildcards. Either one of these can be trained to recognize intents with wildcard values in their training data. Just use an asterisk ( like this - "*" ) for the wildcard.
You don't have to train Conversation with every possible utterance, it learns from it's training data. So if you provided the service a series of utterances like "describe apples", "describe oranges", "describe fireflies", and "describe astrophysics", and then associated all of them with an intent of "#provide_description", then the Conversation service would indicte this intent for requests like "describe math".
Please also try to use real utterances for your training. I am not sure that your users will speak in two word sentences all of the time. Provide enough training data for each intent so the service is able to learn the various different ways people express the same intents.
I know that similar questions have been asked in different ways here but still I see no solution for it...
I would like to add a restriction which states that individuals of class A have exactly 1 data type property value. I have been trying i.e. inserting hasXValue exactly 1 on equivalent classes Protege tab. Also, I have tried also combining min and max restrictions. However, as stated by other people´s posts, it is consistent to have 0 or 1 declaration of value but not 2. I have understood some explanations about the world assumption in OWL but then I would like to know which kind of axiom it could be used for doing this restriction.
In fact, the easiest solution that worked for me is by querying within a SPARQL ASK query, looking the no existence of an instance that pertains to certain class and does not have a data type property value (I have use FILTER NON EXISTS). In this way, I can have a true/false value stating that there is or not any individual with no data type property value declaration. However, I would like the reasoner to say that the model is inconsistent in this case.
My objective is that if I have to declare a lot of instances of a class that must have i.e. an ID, not miss any declaration. Moreover, I would like not having to execute a query for checking it. Thus, I though that cardinality restrictions were the correct choice.
Any help on this? Thanks in advance!
If I'm not mistaken, you are trying to use OWL for validation, which requires a closed world interpretation of the semantics to get the kind of inconsistency errors you'd like to see. As you've noticed, out of the box, you're not going to get that behavior because that's not what OWL was designed for.
There was a workshop on this exact topic, and now there is a W3C working group to explore how to do validation in a standardized way.
Stardog's implementation of integrity constraints uses OWL (Manchester) syntax, amongst others, for authoring constraints, which you could create in Protege, but Stardog itself doesn't have a Protege plugin. As an aside, it translates constraints into SPARQL queries which use FILTER NOT EXISTS much in the same manner as you did by hand, except that it does so automatically.
Other inputs to the working group are SPIN and SHEX. SHEX is not worth looking at, but SPIN could be another decent option for you. It won't, as far as I know, work with Protege, but it is integrated with an IDE (TopBraid) and has a SPARQL based syntax.
I often write code that has a dependency on a database entity. I want to minimize the coupling between those different systems (or make it explicit and robust).
Example: I have a dropdown list of error categories, the users can define new categories, but one category is special in that errors belonging to it get an extra input field. So the system needs to know when the user has selected the special category and this special category is not allowed to just disappear.
How would you handle that special category? Would you match on on the category name or id? would you put the entity in the migration or have your code regenerate it as needed? Do you omit it from the database and have it only exist in your code? I find myself picking new solutions every time this problem presents itself, but I'm never quite satisfied with them.
Has anyone found a satisfactory solution? What drawbacks have you found and how have you mitigated them?
I dislike special case code, so I would design it to all be in the data model. The database would get a can delete field, and a has special entry field with some way to describe what that special input is. I would also try to make sure that I didn't over design the special input stuff since there is only this case so far.
I work for a billing service that uses some complicated mainframe-based billing software for it's core services. We have all kinds of codes we set up that are used for tracking things: payment codes, provider codes, write-off codes, etc... Each type of code has a completely different set of data items that control what the code does and how it behaves.
I am tasked with building a new system for tracking changes made to these codes. We want to know who requested what code, who/when it was reviewed, approved, and implemented, and what the exact setup looked like for that code. The current process only tracks two of the different types of code. This project will add immediate support for a third, with the goal of also making it easy to add additional code types into the same process at a later date. My design conundrum is that each code type has a different set of data that needs to be configured with it, of varying complexity. So I have a few choices available:
I could give each code type it's own table(s) and build them independently. Considering we only have three codes I'm concerned about at the moment, this would be simplest. However, this concept has already failed or I wouldn't be building a new system in the first place. It's also weak in that the code involved in writing generic source code at the presentation level to display request data for any code type (even those not yet implemented) is not trivial.
Build a db schema capable of storing the data points associated with each code type: not only values, but what type they are and how they should be displayed (dropdown list from an enum of some kind). I have a decent db schema for this started, but it just feels wrong: overly complicated to query and maintain, and it ultimately requires a custom query to view full data in nice tabular for for each code type anyway.
Storing the data points for each code request as xml. This greatly simplifies the database design and will hopefully make it easier to build the interface: just set up a schema for each code type. Then have code that validates requests to their schema, transforms a schema into display widgets and maps an actual request item onto the display. What this item lacks is how to handle changes to the schema.
My questions are: how would you do it? Am I missing any big design options? Any other pros/cons to those choices?
My current inclination is to go with the xml option. Given the schema updates are expected but extremely infrequent (probably less than one per code type per 18 months), should I just build it to assume the schema never changes, but so that I can easily add support for a changing schema later? What would that look like in SQL Server 2000 (we're moving to SQL Server 2005, but that won't be ready until after this project is supposed to be completed)?
[Update]:
One reason I'm thinking xml is that some of the data will be complex: nested/conditional data, enumerated drop down lists, etc. But I really don't need to query any of it. So I was thinking it would be easier to define this data in xml schemas.
However, le dorfier's point about introducing a whole new technology hit very close to home. We currently use very little xml anywhere. That's slowly changing, but at the moment this would look a little out of place.
I'm also not entirely sure how to build an input form from a schema, and then merge a record that matches that schema into the form in an elegant way. It will be very common to only store a partially-completed record and so I don't want to build the form from the record itself. That's a topic for a different question, though.
Based on all the comments so far Xml is still the leading candidate. Separate tables may be as good or better, but I have the feeling that my manager would see that as not different or generic enough compared to what we're currently doing.
There is no simple, generic solution to a complex, meticulous problem. You can't have both simple storage and simple app logic at the same time. Either the database structure must be complex, or else your app must be complex as it interprets the data.
I outline five solution to this general problem in "product table, many kind of product, each product have many parameters."
For your situation, I would lean toward Concrete Table Inheritance or Serialized LOB (the XML solution).
The reason that XML might be a good solution is that:
You don't need to use SQL to pick out individual fields; you're always going to display the whole form.
Your XML can annotate fields for data type, user interface control, etc.
But of course you need to add code to parse and validate the XML. You should use an XML schema to help with this. In which case you're just replacing one technology for enforcing data organization (RDBMS) with another (XML schema).
You could also use an RDF solution instead of an RDBMS. In RDF, metadata is queriable and extensible, and you can model entities with "facts" about them. For example:
Payment code XYZ contains attribute TradeCredit (Net-30, Net-60, etc.)
Attribute TradeCredit is of type CalendarInterval
Type CalendarInterval is displayed as a drop-down
.. and so on
Re your comments: Yeah, I am wary of any solution that uses XML. To paraphrase Jamie Zawinski:
Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems.
Another solution would be to invent a little Domain-Specific Language to describe your forms. Use that to generate the user-interface. Then use the database only to store the values for form data instances.
Why do you say "this concept has already failed or I wouldn't be building a new system in the first place"? Is it because you suspect there must be a scheme for handling them in common?
Else I'd say to continue the existing philosophy, and establish additional tables. At least it would be sharing an existing pattern and maintaining some consistency in that respect.
Do a web search on "generalized specialized relational modeling". You'll find articles on how to set up tables that store the attributes of each kind of code, and the attributes common to all codes.
If you’re interested in object modeling, just search on “generalized specialized object modeling”.