# A FAIR Resource Recommender System for Smart Open Scientific Inquiries
## 3 The Deep Web Communication Protocol
### Message Structure and Data Model
LLaMA 3.3 performs the best on exact match metrics--site, page, and access path--indicating strong semantic alignment between query and schema. However, it is the slowest model by a wide margin, with many queries taking over 30 s and some exceeding several minutes (Figure 5). This slow response is due to its larger model size and long completions, especially during access path reasoning. DeepSeek-R1 offers the best overall trade-off. It achieves the highest structured data retrieval success rate (Figure 4), performs competitively on exact match metrics, and has the lowest average retrieval time. However, it underperforms slightly in schema alignment, especially when compared to LLaMA 3.3. This suggests that DeepSeek is able to find alternative valid paths when the exact schema is missed. Its speed and consistency make it a strong candidate for default use, particularly when users prioritize responsiveness. Although Qwen3 exhibits a reasonable degree of accuracy, its form execution is inconsistent. Its slightly lower success rate and lower schema match can be explained by this. Gemma, on the other hand, executes tasks quickly and consistently, but it struggles with precise matching, especially when it comes to determining the right schema. When reasoning is needed to infer intent, it struggles, but it does well on simpler queries. Although \begin{table}
\begin{tabular}{l l c c c c} \hline \hline
**Model** & **Query Type** & **Avg. Time (s)** & **Site Match** & **Page Match** & **Schema Match** \\ \hline \multirow{3}{*}{Llama3.3} & Complex & 40.84 & 0.592 & 0.449 & 0.449 \\  & Simple & 37.76 & 0.755 & 0.612 & 0.612 \\  & Overall & 39.30 & 0.673 & **0.531** & 0.531 \\ \hline \multirow{3}{*}{DeepSeek-R1} & Complex & 13.80 & 0.571 & 0.449 & 0.388 \\  & Simple & 13.34 & 0.694 & 0.592 & 0.510 \\  & Overall & 13.57 & 0.633 & 0.520 & 0.449 \\ \hline \multirow{3}{*}{Qwen3} & Complex & 24.83 & 0.531 & 0.429 & 0.367 \\  & Simple & 34.51 & 0.612 & 0.531 & 0.469 \\  & Overall & 29.67 & 0.571 & 0.480 & 0.418 \\ \hline \multirow{3}{*}{Gemma} & Complex & 13.81 & 0.531 & 0.408 & 0.367 \\  & Simple & 12.64 & 0.612 & 0.490 & 0.449 \\ \cline{1-1}  & Overall & 13.22 & 0.571 & 0.449 & 0.408 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Evaluation results across four language models on simple, complex, and combined (overall) query sets. Metrics include average end-to-end retrieval time (in seconds), and match rates at the site, page, and schema levels, which reflect how accurately the system localizes data access targets under different reasoning conditions. Match rates are reported as proportions in the range [0,1]. both models show promise, there is still a need for improved alignment between execution robustness and schema understanding. Complex queries resulted in lower site, page, and schema match rates across all models. This is to be expected since complex queries lack explicit schema terms and instead rely on implicit reasoning. It is simpler to match the indexed DWCP records with simple queries that directly reference form fields or column names. Even for complex queries, success rates are still high, demonstrating that the system can still produce useful data even in the absence of precise alignment. Beyond retrieval accuracy, FAIRFind advances a broader vision of transforming static metadata registries into interactive, executable infrastructures. At the core of this transformation is the DWCP protocol, which formalizes each access point, whether a form, table, or downloadable file, as a structured object containing metadata, access type, form fields, and XPath-based selectors. AI agents can now programmatically interact with deep web content that was previously unavailable to automated systems owing to this abstraction. FAIRFind transforms FAIRsharing into a living interface by using natural language queries to generate executable, reusable access paths, where references become entry points to real data.