Wiki source code of Requête en langage naturel

Last modified by jhurst on 2022/11/14 09:18

Show last authors
1 {{ddtoc/}}
2
3 = Prerequisites =
4
5 * Cubes in your wallets recently synchronized
6
7 = Creating flows with text query =
8
9 Digdash offers the possibility to create flows in some clicks with natural language.
10
11 * Via the dashboards editor
12
13 |[[image:text_query_en_html_f2d69e963b6dfe7b.png||height="177" width="275"]]
14 |**Dashboards editor **>** Creating new graphics **>** In natural language**
15 |[[image:text_query_en_html_d3b55a8e10123fdd.png||height="207" width="266"]]
16 |In the showing dialog, you can enter you query in the search bar.
17 |[[image:text_query_en_html_98fd1f57c633562.png||height="184" width="318"]]
18 |Choose a flow in the results list (we are going to pick the first one)
19 |[[image:text_query_en_html_c8e99a6b1e0bc9e9.png||height="170" width="355"]]
20 |And save the flow in the current wallet.
21 |[[image:text_query_en_html_cddc52d001b3a1e9.png||height="213" width="355"]]
22 |Give a name to your flow.
23 |[[image:text_query_en_html_f70ed4175e1093f9.png||height="175" width="355"]]
24 |The new flow will be added to your dashboard editor and you will find it in the existing graphics list.
25
26 * Via the dashboard
27
28 It is also possible to add a « Text query » element in your dashboard in order to create flows on the fly.
29
30 |[[image:text_query_en_html_21e80dc5c36d4220.png||height="468" width="202"]]
31 |**Dashboards editor **>** Additional content **>** Elements **>** Text query**
32 |[[image:text_query_en_html_f940b7f7ead63723.png||height="223" width="325"]]
33 |Add the element in your dashboard editor.
34 |[[image:text_query_en_html_81f6639240d4c264.png||height="193" width="288"]]
35 |(((
36 According to your query, you may filter on some measures/dimensions.
37
38 You would better have a « Filtered elements » element in your dashboard to remove these filters for the potential next queries.
39
40 **Dashboard editors **>** Additional content **>** Elements **>** Filtered elements**
41 )))
42 |[[image:text_query_en_html_758db70155096f91.png||height="123" width="325"]]
43 |You will find those elements dashboard side.
44
45 {{{
46 }}}
47
48 = Composition of a text query =
49
50 Digdash allows you to create flows from data models in natural language.
51
52 Digdash mainly rests on keywords to suggest you the most relevant flows and the names of your data models’ columns.
53
54 So a query is basically composed of measures names from your data model and/or dimensions names, followed (or not) by flows names and/or sorting operations.
55
56 We shall later explain how important query terms are important.
57
58 = Results for a text query =
59
60 [[image:text_query_en_html_c7eda020d25db863.png||height="117" width="550"]]
61
62
63 //__Screenshot: Results for a text query__//
64
65 Results for a text query are presented in list, with its associated flow, sorted by its relevance and a score. The more the score is high, the more the suggested flow is considered as relevant. Also, the cube name is mentioned so is a description of the flow.
66
67 We shall later see in this document which are the criteria that could have an influence on the score of a result.
68
69 = Choices of graphics =
70
71 For a given query, you will be suggested a list of results of multiple graphics, depending on your query members.
72
73 Nevertheless, you can require a particular graphic, as long as it remains coherent (the query « Cost in line » has no sense).
74
75 The numbers of members for a cube has an incidence. Indeed, when a query, even coherent, has too many members to show, you will be suggested a more adapted graphic.
76
77 Here are the keywords to use for the choice of graphics:
78
79 |**Charts name**|**Keywords**
80 |Pie chart|« pie »
81 |Gauge|« gauge »
82 |Progress bar|« progress bar »
83 |Energy bars|« energy »
84 |Arrow indicator|« arrow »
85 |Column chart|(((
86 « column »
87
88 « histogram »
89 )))
90 |Bar chart|« bar »
91 |Map chart|« map »
92 |Scatter chart|« scatter »
93 |Bubble chart|« bubble »
94 |Line chart|« line »
95 |Zone chart|(((
96 « area »
97
98 « zone »
99 )))
100 |Radar chart|« radar »
101 |Tab chart|« table »
102 |Indicator|« indicator »
103 |Cross table|« cross table »
104 |OLAP table|(((
105 « OLAP table »
106
107 « OLAP»
108 )))
109 |Text chart|« text »
110
111 //__Table presenting keywords for the different flows__//
112
113 = Sorting =
114
115 It is possible for you to use sorting operations with the following keywords :
116
117 |**Sorting**|**Keywords**|**Queries examples**
118 |Ascending|(((
119 « sort » (ascending)
120
121 « sorted » (ascending)
122
123 « ascending »
124 )))|(((
125 « Cost by region in France in 2006 sorted by cost in table »
126
127 «  Cost by region in France in 2006 sorted in table »
128
129 «  Cost by region in France in 2006 ascending in table »
130
131 «  Cost by region in France in 2006 sorted in ascending order in table »
132 )))
133 |Descending|(((
134 « sort » (descending)
135
136 « sorted » (descending)
137
138 « descending »
139 )))|(((
140 «  Cost by region in France in 2006 sorted by cost in table »
141
142 «  Cost by region in France in 2006 descending in table »
143
144 «  Cost by region in France in 2006 sorted in descending order in table »
145 )))
146
147 //__Table presenting keywords for sorting operations__//
148
149
150 = Trend of a measure =
151
152 A measure has a trend. It can be stable (trend by default), increasing or decreasing:
153
154 {{{
155 }}}
156
157 |**Tendance**|**Signification**
158 |STABLE|Default trend: The bigger the better
159 |INCREASING|(((
160 The bigger the better
161
162 //Example : for a quality//
163 )))
164 |DECREASING|(((
165 The lowest the better
166
167 //Example : for a cost//
168 )))
169
170 __//Table presenting possible trends for a measure//__
171
172 You can change the trend of a measure via the Digdash Enterprise Studio, in the data source advanced configuration, in the properties part of a measure.
173
174
175 //__Definition of a measure’s trend in Digdash’s Studio Enterprise__//
176
177 * Impact of a measure’s trend
178
179 Trend has an impact on the sorting order. Indeed, if the type of sorting is not explicitly mentioned, the kind of sorting will be based on the measure’s trend. Consequently, we will get an ascending sort for a stable or increasing trend and a descending sort for a decreasing trend.
180
181
182
183 |**Trend**|**Queries examples**|**Sort**
184 |STABLE|(((
185 « Duration by state sorted »
186
187 Duration is a measure with a stable trend
188 )))|//The sorting of measure Duration on dimension state will be descendant//
189 |INCREASING|(((
190 « Quality by state sorted »
191
192 Quality is a measure with an increasing trend
193 )))|//The sorting of measure Quality on dimension state will be descendant//
194 |DECREASING|(((
195 « Cost by state sorted »
196
197 Cost is a measure with a decreasing trend
198 )))|//The sorting of measure Cost on dimension state will be ascendant//
199
200 //__Table with examples presenting impact of a measure’s trend on sorting orders__//
201
202 {{{
203 }}}
204
205 = The best / the worst, the top / bottom =
206
207 It is possible to get the X best/worst members of the results of your query using these keywords:
208
209 |**Cases**|**Keywords**|**Example**
210 |The X best|(((
211 « Top »
212
213 « biggest »
214
215 « best »
216 )))|(((
217 The best cost in France
218
219 The 5 best costs in 2016
220
221 The 2 biggest costs in Europe
222
223 Top 3 of costs in France in 2016
224 )))
225 |The X worst|(((
226 « Worst »
227
228 « bottom »
229
230 « smallest »
231 )))|(((
232 The worst cost in France
233
234 The 5 worst costs in 2016
235
236 The 2 smallest costs in Europe
237 )))
238
239 //__Table presenting keywords for best/worst, top/bottom__//
240
241
242 = Aggregation =
243
244 You can define an aggregation method for the measures of your query using these keywords :
245
246 |**Aggregation**|**Keywords**|**Queries examples**
247 |Sum|« sum »|« Sum of cost »
248 |Average|« average »|« Average of cost »
249 |Minimum|« min »|« Min of cost  »
250 |Maximum|« max »|« Max of cost  »
251
252 //__Table presenting keywords for aggregation__//
253
254
255 = Targets =
256
257 It is possible to apply targets on measures mentioning the following keyword :
258
259
260 |**Keyword**
261 |« target »
262
263 __//Table presenting the keyword for targets//__
264
265
266 You can also directly mention the name of the targets you want to apply.
267
268
269 |**Example**
270 |Given a data model with the following columns(((
271 |**Dimensions**|**Measures**
272 |Date|Quality
273 |Type of line|Cost (with target « Targ »)
274 )))
275 |(((
276 Example 1 : « Cost in gauge with target »
277
278 * Every measure has one target applied on it.
279
280 Example 2 : « Cost in gauge avec Obj »
281
282 * The target « Targ » is applied on the associated measure « Cost ».
283 )))
284
285 __//Table with example presenting the use of target in text query//__
286
287
288 = Use of synonyms =
289
290 Text query takes in charge synonyms of your query members.
291
292 == Creating synonyms dictionaries ==
293
294 To use synonyms in text query, you first need to import a synonyms dictionary in Digdash.
295
296 Please refer to the documentation called « synonyms_dictionary_en.pdf » to import a synonyms dictionary in Digdash.
297
298 == Activating synonyms dictionaries ==
299
300 You then need to check if the use of synonyms dictionaries is activated for text query in the server configuration.
301
302 [[image:text_query_en_html_d057beaef5d1f988.png||height="238" width="444"]]
303 \\
304
305 [[image:text_query_en_html_f1d5ad7376929373.png||height="241" width="413"]]
306 \\
307
308 In the server configuration page, at the bottom of the page > **Advanced >>** > Category **Synonyms dictionaries** > Checkbox **Use synonyms dictionaries for text query**
309
310 [[image:text_query_en_html_f1e4eedd6b1df4.png||height="114" width="508"]]
311 \\
312
313 //__Screenshot: Activation of the use of synonyms dictionaries for text query__//
314
315 == Use case ==
316
317 |**Example**
318 |Given a data model with the following columns(((
319 |**Dimensions**|**Measures**
320 |Date|Quality
321 |Type of line|Cost
322 )))
323 |(((
324 In that case, the query
325
326 « Price by sort of line »
327
328 is equivalent to th query
329
330 « Cost by type of line »
331
332 (« price » is a synonym of « cost » and « sort » is a synonym of « type »).
333
334 __**NB**__ : This is valid only if your synonyms dictionaries contains these synonyms.
335 )))
336
337 //__Table with example presenting a use case of text query with synonyms__//
338
339 = Scores for a result of a text query =
340
341 Queries results are ordered according to their relevance and the best score can reach a 5 out of 5.
342
343 The score for a result may vary for different reasons.
344
345 * Importance of the query members
346
347 Indeed, a result will be better marked if the query is composed of the exact columns’ names of your data models.
348
349 A query is then considered as less good if it contains partial names of your columns, or synonyms.
350
351 |(% colspan="3" %)**Example**
352 |(% colspan="3" %)Given a data model with these columns(((
353 |**Dimensions**|**Measures**
354 |Date|Quality
355 |Type of line|Cost
356
357
358 )))
359 |(((
360 **Query 1 :**
361
362 **With the exact names**
363 )))|(((
364 **Query 2 :**
365
366 **With partial names**
367 )))|(((
368 **Query 3 :**
369
370 **With synonyms**
371 )))
372 |« Cost by type of line »|« Cost by type »|« Price by sort of line »
373 |With only exact terms, the results can be well-marked.|With partial names, the results can be less well-marked.|(((
374 « price » is a synonym of « cost », « sort of line » is a synonym of « type of line ».
375
376 This query is different from the original query, the score will be low.
377 )))
378 |Score* : 5/5|Score* : 3/5|Score* : 2/5
379 |(% colspan="3" %)* indicated scoes are just to illustrate our example
380
381 //__Table with example presenting how important query members are important__//
382
383 * Importance of the suggested type of graphics
384
385 The results list for a query suggests graphics more or less relevant for what is expected. Given the nature of the query members, some flows will be considered less relevant, hence a lower score for them.
386
387
388