I am wondering what is the ideal way to define entities of different kinds with interval value. e.g. with maximum and minimum number.
I tried to define a number-intervalentity with min and max values. Then defined a price-range composite entity with #number-interval + #sys.currency-name. (See attached images)
There are two issues with this. First, there are too many ways for user to say it. For instance, it can recognize User says: above 12 USD but can not recognize User says: more than 12 USD
Is there any better way to define it that uses system entities?
For example, let's say we want to collect two different values from user.
The other problem is, let's say we want to collect two different kind values from user. How to distinguish the correct entity (price_range vs. size_range)?
Example:
user says: 1200 to 1500 in get_price action. should return #price-range
user says: 9-10 in get_size action. should return #size-range
P.S.
Entities:
There's currently no range/interval system entity (all Dialogflow system entities can be found here)
To answer the second part of your question: Get 2 different kinds of values from the user. You can use contexts to narrow down the options (see documentation)
Question: "What is the price?" (output context: price)
Answer: "10-50" (context: price)
Intent get_price (input context: price) <- this will trigger
Intent get_size (input context: size) <- this will never trigger
Only an intent with the same context can trigger. If an intent doesn't have an input context it can always trigger (for example a "help" intent without a context).
Related
so my company wants me to learn ABAP for SAP and I have started on the road to learn this. My background is mainly VB.net and sqlserver with T-SQL but also have experience in c#.
With ABAP though I am needing some clarification or confirmation on the understanding of Data Types and Domain. If anyone can help.
My understanding currently is we have a table, in the table we have fields and the fields have data types and lengths if needed. Example: We have a table Customer, I could have a customerNumber field with the data type of char(10). To me this mean in the table customer we have a field called CustomerNumber that will have 10 characters.
However with ABAP we have Domains, Data elements then the field, does this mean we have a field named whatever we want. As the field could mean anything we assign a data element which has the descriptions of the sort of data stored within the field. However to store the format and data type we need to assign the Domain to the Data element.
For example I call a field ZCUSNO, currently this means nothing however if I assign the ZCTNMR (with description of customer number) Data element this tells us that the field ZCUSNO is ZCTNMR so ZCUSNO is a customer number field.
Now within the data elements we would have a domain and for our example ZCTNMR data element (the customer number) we could assign ZCTDOM as the domain which would be what I recognise as the data types so Char 20, Char 100 or integer field etc.
Is my understanding correct on this? and could someone give me a clear indication of what the difference between a Domain > Data Element is against what I would know as data types in sqlserver.
Thanks
I don't know if it's 100% correct, but that's is the way I use, like you say.
You can reuse the Domain, If you don't plan to reuse you can use direct the Data Element and refer this to a built-in-type.
Data Element is to define semantic of the field, like label, translation, etc
Domain is to define techinical info of the field, like Type, conversions, predefined Values,e tc
E.G.
Domain:
DOM_VALUE you define it's 10 position and 2 Decimals
Data Element:
UNIT_VAL you refer it to DOM_VALUE and define label as "Unit Value"
TOTAL_VAL you refer it to DOM_VALUE and define label as "Total Value"
Your understanding is pretty correct and not much can be added here.
You should clearly get the main thing.
Domains store technical data (decimal points, length, type, predefined values and so on)
Data elements store semantic data (labels, texts, search help binding, etc.)
Not every table field has data element (they can possess builtin type) but every field has type (either primitive or wrapped in data element).
If you wanna use your field in screens (Dynpros), ALV grids or other reports, then create data elements that will bear business meaning of your field.
If you use this field just for calculations or other utility internal tasks, then don't bother yourself.
As usual table date field (type of variable) uses data element which uses domain.
When you create fields in table and use predefined types instead of data elements you will have some problems in future, when you'll need to see the data on alv_grid.
Actually, you will see that you have some problems even before this (when you will try to make a maintenance view the header will have something like "+" symbol).
And of course we usually try to create 1 domain for 2 and more Data Elements.
In domain you talk about main logic.
In Data Element I always talk about Field label settings (how it'll show in future and some other things)
Final: Actually, the good practice, as I think to create a domain for data element, it may help you in future.
I hope that it helps you. Good luck!
Is there a list of advanced filtering and sorting of parameters for the Watson Data Kits API, specifically the Travel Data kit? I want to be able to limit responses to certain keywords. I would also like to be able to combine various flags, to really optimize my results.
As for your first question,
Use `f` to add the filter option to a parameter. This option indicates that the condition set by the parameter it prefaces must be met in order to be included in the result.
Note: Each parameter has a `f` option added by default.
Example:
In /attractions?address=nyc&attraction_keyword=`f`theater, the response will return only attractions whose name includes the keyword theater.
For your second question,
Note: the rank option must come last. address, location, and radius parameters only have `f` option available.
Example: - In /attractions?address=nyc&attraction_keyword=`u!25`theater, the response will include attractions in results whose names do not match the keyword theater AND have the rank value of attraction_keyword set to 25.
I have a table called transactions. Within that is a field called ipn_type. I would like to create separate table occurrences for the different ipn types I may have.
For example, one value for ipn_type is "dispute". In the past I would create a global field called "rel_dispute" and I would populate that with the value of "dispute". Then I could create a new table occurrence of the transactions table, and make a relationship based on transactions::ipn_type = transactions::rel_dispute. This way only the dispute records would show up in my new table occurrence.
Not long ago, somebody pointed out to me that this is no longer necessary, and there is a simpler way to setup such a relationship to create a new table occurrence. I can't for the life of me remember how that was done, though.
Any information on this would be greatly appreciated. Thanks!
To show a found set of only one type, you must either perform a find or use the Go to Related Record script step to show only related records. What you describe as your previous setup fits the latter.
The simpler way is to perform a find - either on demand, or by a script triggered OnLayoutEnter.
The new 'easy' way is probably:
using one base relationship only and
filtering only the displaying portal by type. This can be done with a global field, a global variable containing current display type. Multiple portals with different filter conditions are possible as well.
~jens
I have a REST service that allows people to put in a course title as part of the query to get scores, but, sometimes they may want to get a group, such as Calculus% for Calc 1, 2 and 3.
But, what is the best way to give them an option that makes sense?
For example, I have http://localhost/myrest/any/any/Calculus III
where the first two parameters are student id and some grade category.
I don't think having http://localhost/myrest/any/any/contains/Calculus III is a good use as then I will need to force them to use equals if that is what they are looking for.
Another option is http://localhost/myrest/any/any/Calculus% or http://localhost/myrest/any/any/%Calc% is another option, but then you have removed the option to easily use % as an allowed character.
So, to give additional filtering options in a REST URL, what is the best (defined as simplest/most intuitive for the user) way to allow contains or starts with.
In your system, would the following query list all subjects in the grade category?
http://localhost/myrest/any/any/
If yes, then one option you can consider is extracting the non-exact subject name into a GET parameter. Thus without breaking the current logic where having a full name of the subject in the URL provides the score for that subject, you'd also have the ability to filter the list of subjects within the same grade category by means of the GET parameter.
For example:
http://localhost/myrest/any/any/?search=Calculus*
... could provide a result like this:
<subjects>
<subject uri="/myrest/any/any/Calculus%20I">A</subject>
<subject uri="/myrest/any/any/Calculus%20II">B</subject>
<subject uri="/myrest/any/any/Calculus%20III">C</subject>
</subjects>
I've been recruited to work on a form for tracking specimens. Each specimen is associated with a subject; each specimen also has a particular slot in a 9 x 9 storage box. For ease of data entry, I think it would be best if the Access form mirrored the box itself (and the paper forms that will be used to enter data into Access): nine columns by nine rows, with each element consisting basically of a text box for the specimen ID. This is basically how I'd like it to look:
So the data entry person would essentially type in the box number and specimen IDs, then click "Create Records" to pop all of those records into existence (you can see some other stuff going on here, but that's not really important right now). I'm not really sure about the best way to code this, however. Right now, the best process I can think of is to: 1) run an insert query to create the box if it doesn't exist, 2) run an insert query to create the subject (person), if it doesn't exist, and 3) run an insert query for each specimen, hard-coding in its row and column (e.g. box_col = 'A', box_row = '1').
Note: the subject ID and specimen ID would both be parsed out of the ID field - it's goofy, not my idea, but that's how it's set up. I can handle that, though.
This is a certainly a kludge, but I'm not sure what else to do and most of what I've googled up hasn't been pertinent to multiple-record creation from a single form. Is there a better way to do this? Should I simply abandon the idea and go with a more traditional bound subform approach?
This could be all done in a sub form - however, I assume for simplicity (less clicks, easier user experience, and intuition) you've designed it so that the end user sees everything he /she need to enter. There is nothing wrong with doing it this way. Once the data is all entered just have a button on the form that does the multiple inserts at once.
Start at 1 and include 9 iterations each time issuing a new INSERT statement.
Once the statement has been completed I would personally put a little check mark next to each row so that if an insert succeded it would check it true, else false. You could be nifty and use a green image / red image. After it has completed the process all fields should be cleared allowing additional entry.
I don't see an issue with what you have.
FRIG. I just lost ten minutes of typing. This is why I don't care for web based forms. Although to be fair this is the first time this has happened on StackOverflow.
Do you really need to view the data later in the same format as it's entered. If they can just view regular subforms that's at least half the work as you no longer need to do updates of this form.
Also note that there is a lifetime amaximum of 768, if I recall correctly, controls per form. 9 x 9 x 2 is 162 so you'll be ok there. However if you decide to delete and recreate lots of cotrols you could be in trouble. If you do hit that limit I think saving the form under a separate name should reset the counter.
Note you can use the following construct to refer to controls and make life easier.
Me.Controls("abc" & Row & column)
For example in the After Update of the type control you could use
call InsertRecords(3, "B")
sub InsertRecords(row as integer, Column as string)
....
cboTypeValue = Me.Controls("cboTypeID" & Row & Column)
....
This could be used as some kind of native access controls only grid.
If someone would post an example of how to create custom unbound subform with row for each unbound record and a code to loop and save it to the tables would be just great.
There wouldn't be as much controls and it wouldn't have any limits by the numbers of fields on form.