# Ad Hoc Data Foraging in a Life Sciences Community Ecosystem Using SoDa +
## 3 SoDa Architecture
### Application Design
#### 3.4.2 Query Builder Interface
The interface in Figure 6 shows several fillable entries that correspond to the extract statement in Figure 5. The Deep Web DB entry allows entering the database URL \(\varphi\) in the extract statement in Figure 5. The Extract entry enables listing the columns that users wish to retrieve from the deep web database. This is called the \"user view\" of the database. It is interesting to note that these column names in the user view need not match exactly with the column names in the deep web database at \(\varphi\), called the \"database view\". The semantic match between the two views are resolved and a proper correspondence is established using the schema matcher selected by the user using the Schema Matcher entry just below. For this edition of SoDa, the schema matcher Cupid [16] is a default choice. Every deep web data extraction requires a wrapper. A wrapper can be pre-built and stored using the CroW wrapper generation tool or can be constructed live using CroW following the \"Generate New Wrapper\" option. The drop-down menu of the Wrapper entry option allows a stored wrapper to be selected instead. The Form Filler entry helps an end-point constructor to be selected from the stored Needle description of a deep web  
Figure 8: QBuild interface: The table shows the execution of the extract query constructed in Figure 6. The table can be stored in multiple formats—TXT, CSV, JSON, or as a relational table. database. Usually, a form filler generates individual end-points from the entries in the input table \(r\) of the extract statement. Finally, the input table \(r\) can be selected from the drop-down menu found toward the bottom in this interface. The current edition of SoDa allows only one column as input parameter to the deep web database (Future editions will allow multiple parameters and remove this restriction).The filter entry allows a Boolean condition to be written to exclude unwanted parameters in the input table. SQL Queries  
While writing an extract query is straightforward, with only a few options, building an SQL query, on the other hand, could turn complex. Figure 7 shows construction of a simple join query using two stored tables--Dispenet_Diseases and MikDB, selected from the drop-down menus. A Boolean filter condition can be specified using the filter constructor below. The top Show option allows the columns that the users want to see to be listed. Note that, as discussed earlier, the tables selected from the drop-down menus are usually stored query specifications; the corresponding tables are computed live, and they are potentially extract queries. Though a relatively large class of SQL queries are simple and involve only select-project-join (SPJ) operations over a set of relations, many require complex subqueries and correlated subqueries. The logic and construction process of such queries are pretty tedious and require substantial expertise in SQL. To simplify query construction using these SQL features, SoDa supports two interfaces--subquery and correlated subquery. Basically, these options allow queries constructed using the Query option to be linked in a systematic way using a graphical user interface. A discussion on subquery and correlated subquery is involved but is outside the scope of this paper. An independent and separate article on query construction using QBuild is being planned for publication soon, and we will not discuss the details in this article any further. Figure 9 shows the result of the SPJ query shown in Figure 7.