---
title: 'CrowdQuery (CQ): Multifaceted Query Approaches'
url: https://www.emergentmind.com/topics/crowdquery-cq
type: topic
---

# CrowdQuery (CQ): Multifaceted Query Approaches

CrowdQuery (CQ) is not a single universally fixed term in the research literature represented here. One explicit use of the name denotes an adaptive crowdsourcing framework for reducing uncertainty in probabilistic schema matching by asking simple binary questions about candidate correspondences [1809.04017]. In adjacent literatures, however, the same abbreviation also denotes competency questions in ontology engineering and knowledge-graph question answering, conjunctive queries in OWL reasoning, collaborative queries in cloud-edge-device systems, and a density-guided query module for crowded-scene detection [2105.09574; 2505.13572; 2107.00369; 2508.15285; 2509.08738]. The term therefore requires domain-specific disambiguation.

## 1. Terminological scope and major usages

In the material considered here, “CQ” functions as an overloaded abbreviation rather than a single settled technical object. The most direct use of **CrowdQuery (CQ)** appears in schema matching, where the crowd is queried to reduce uncertainty over alternative mappings. In ontology engineering, **CQ** usually abbreviates **competency question**. In description-logic reasoning, it abbreviates **conjunctive query**. In distributed systems, it can denote **collaborative query** execution. In computer vision, **CrowdQuery** names a module that guides transformer queries with density information [1809.04017; 2105.09574; 2107.00369; 2508.15285; 2509.08738].

| Usage of CQ | Domain | Representative paper |
|---|---|---|
| CrowdQuery | Schema matching via crowdsourcing | [1809.04017] |
| Competency question | Ontology engineering and KG QA | [2105.09574], [2505.13572] |
| Conjunctive query | OWL 2 query answering | [2107.00369] |
| Collaborative query | Cloud-edge-device execution | [2508.15285] |
| CrowdQuery | Density-guided detection in crowded scenes | [2509.08738] |

A common misconception is to treat these usages as interchangeable. The literature instead shows that identical initials are attached to substantially different objects: a human-in-the-loop uncertainty-reduction framework, a requirements artifact for ontologies, a formal database/logic query class, a systems-execution mode, and a vision module.

## 2. CrowdQuery in schema matching

In its most explicit database-theoretic form, CrowdQuery is a method for reducing the uncertainty of schema matching by decomposing the global matching problem into simple **Correspondence Correctness Questions (CCQs)**. The input is a probabilistic set of possible matchings \(R=\{m_i\}\), with probabilities summing to \(1\). A correspondence \(c\) is an attribute-to-attribute or subset-to-subset match, and the associated CCQ asks whether \(c\) should exist in the correct matching [1809.04017].

The probability that a correspondence is correct is defined by summing the probabilities of all matchings that contain it:
\[
\mathbb{P}(c)=\sum_{\substack{m_i\in R\\ c\in m_i}} \mathbb{P}(m_i).
\]
For a set of correspondences \(U\subseteq C\),
\[
\mathbb{P}(U)=\sum_{\substack{m_i\in R\\ U\subseteq m_i}} \mathbb{P}(m_i).
\]
This construction turns uncertain schema matching into an adaptive question-selection problem: each crowd answer updates the posterior distribution over possible matchings.

A defining feature of the framework is that crowd workers are not assumed to be perfect. Each worker \(W\) has an accuracy rate \(P_W \in [0.5,1]\), interpreted as the probability of answering a CCQ correctly. For a single CCQ \(Q_c\), the answer variable \(A\) satisfies
\[
\mathbb{P}(A=Y)=\mathbb{P}(c)P_W + (1-\mathbb{P}(c))(1-P_W),
\]
\[
\mathbb{P}(A=N)=(1-\mathbb{P}(c))P_W + \mathbb{P}(c)(1-P_W).
\]
The worker’s uncertainty is captured by
\[
H(W)=-P_W\log P_W-(1-P_W)\log(1-P_W).
\]

The central theorem states that the uncertainty reduction from asking one CCQ is
\[
\Delta H_{Q_c}=H(R)-H(R\mid A)=H(A)-H(W).
\]
The same principle generalizes to a set \(S_Q=\{Q_{c_1},\dots,Q_{c_k}\}\):
\[
\Delta H_{S_Q}=H(D_A)-\sum_{t=1}^k H(W_t),
\]
where \(H(D_A)\) is the joint entropy of the answers. The single-question objective is maximized when \(\mathbb{P}(c)\) is closest to \(0.5\), so the most useful question is the one whose truth is most uncertain.

## 3. Adaptive algorithms, optimization, and empirical behavior

The schema-matching version of CrowdQuery implements two operational frameworks: **Single CCQ** and **Multiple CCQ**. Single CCQ repeatedly selects the best available question, publishes it, updates matching probabilities when the answer arrives, recomputes correspondence probabilities, and repeats until the question budget is exhausted. Multiple CCQ maintains \(k\) questions in flight simultaneously; when one or more answers are received, still-waiting CCQs are withdrawn, the probability distribution is updated, and a new set is selected [1809.04017].

The optimization problem for the parallel setting, **Multiple CCQ Selection (MCCQS)**, is shown to be **NP-hard**. The paper therefore uses the submodularity of joint entropy to derive a greedy \((1-1/e)\)-approximation-style method, selecting at each step the correspondence with maximum conditional answer entropy. Both frameworks are accelerated by indexing possible matchings as a binary matrix and by pruning rules that eliminate clearly dominated candidates.

The empirical evaluation combines simulation and Amazon Mechanical Turk deployment. The simulation uses schema-matching results from OntoBuilder on **5 datasets**, **40 schema pairs**, and **400 possible matchings per pair**. In real deployment, each CCQ is posted as an AMT HIT priced at **\$0.05**, and qualification tests are used to estimate worker error rates. The reported behavior is consistent across settings: **Single CCQ** reduces uncertainty faster than random selection and gives the best answer quality, while **Multiple CCQ** improves wall-clock efficiency but degrades as \(k\) grows. On AMT, **Single CCQ with budget 50 achieves over 90% precision and recall**, whereas larger \(k\) values trade answer quality for time efficiency [1809.04017].

This makes the framework a representative instance of adaptive human-in-the-loop query optimization: the crowd is not merely a labeling backend, but a stochastic information source whose value depends jointly on question entropy, worker reliability, and budget.

## 4. Relation to crowdsourced database query processing

The schema-matching formulation sits within a broader line of work that treats the crowd as a query-processing operator. In that literature, crowd-enabled database systems integrate human workers with relational processing for selection, sorting, filling, joins, top-\(k\), skyline, and other operators, typically under explicit cost-latency-quality trade-offs [2204.07883].

A foundational issue is that the closed world assumption no longer holds when the crowd can supply tuples beyond the stored database. “Getting It All from the Crowd” models crowd enumeration as an open-world species-estimation problem, using statistics such as \(f_1\), \(f_2\), sample coverage, Chao84, and Chao92 to reason about completeness and stopping decisions. Its experiments involved **over 25,000 HITs** on AMT over tasks such as US states, UN countries, and ice cream flavors, and introduced crowd-specific phenomena such as streakers and list walking [1202.2335].

Other systems operationalize selective human intervention more directly. **RDF-Hunter** decomposes SPARQL queries into machine-executable and crowd-executable parts using an RDF quality model based on predicate multiplicity, aggregated multiplicity, completeness, disagreement, and uncertainty. On **50 SPARQL queries** over DBpedia, it reports **F-measure values ranging from 0.84 to 0.96** across five domains, with **21 queries** achieving both precision and recall of \(1.0\) [1503.02911]. **Query-driven schema expansion** extends crowd-enabled databases beyond rigid schemas by using Social Web ratings to construct perceptual spaces; from **103,297,638 ratings**, **480,189 users**, and **17,770 movies**, the system infers new perceptual attributes from small expert-labeled samples rather than crowd-labeling every tuple [1203.0057].

Taken together, these systems show that CrowdQuery, in the broader database sense, belongs to a family of hybrid human-machine execution strategies that use the crowd selectively, model worker behavior explicitly, and optimize for uncertainty reduction or completeness rather than raw task volume.

## 5. CQ as competency questions in ontology engineering and KG question answering

A second major meaning of CQ is **competency question**. In ontology engineering methodologies such as **Gruninger and Fox**, **METHONTOLOGY**, and **NeOn**, competency questions are natural-language questions that an ontology should be able to answer; they define scope, guide completeness and correctness assessment, and connect stakeholder requirements to formal ontology artifacts [2105.09574].

This literature has recently moved toward large-scale automation. **BigCQ** is a synthetic resource generated from frequent OWL axiom shapes mined from BioPortal ontologies. Its pipeline normalizes frequent axiom patterns into domain-agnostic shapes, verbalizes them with the ACE verbalizer, converts them into CQ templates, and then formalizes them as SPARQL-OWL query templates. The resulting dataset contains **77,575 distinct CQ templates** and **549 distinct SPARQL-OWL query templates**, with **63.89% coverage** of held-out CORAL competency questions and **45.74% coverage** of CQ2SPARQLOWL queries [2105.09574].

A complementary systems paper, **Q\(^2\)Forge**, treats competency-question generation, SPARQL translation, and refinement as an end-to-end pipeline for knowledge graphs. The workflow has **eight steps**: create KG configuration, extract schema or preprocess the KG, generate competency questions, optionally export CQs, translate a CQ into SPARQL, execute the query and interpret results, judge relevance and refine the query, and export the final question-query set. The system is described as **open-source, generic, extensible, end-to-end**, and its validation loop combines human feedback with an LLM judge that assigns a **grade from 0 to 10** and an explanation [2505.13572].

This branch of the literature is not “crowd query processing” in the database-operator sense. Instead, it uses CQ as a requirements and dataset-construction primitive. Its significance for the broader CrowdQuery label is terminological: the same abbreviation indexes a distinct research program centered on ontology scope specification and question-to-query formalization.

## 6. Conjunctive, collaborative, and other recent CQ usages

Further divergence appears in several recent areas. In OWL reasoning, **CQ** stands for **conjunctive query**. “Computing CQ lower-bounds over OWL 2 through approximation to RSA” studies how to compute tighter lower bounds for CQ answering by approximating OWL 2 ontologies into RSA, improving on PAGOdA’s coarse approximations. Its prototype, RSAComb, is reported to be **up to 2 orders of magnitude faster** than PAGOdA on some LUBM cases when PAGOdA would otherwise require HermiT [2107.00369].

In cloud-edge-device systems, **CQ** denotes **collaborative query** processing. The paper on collaborative scan operators defines a migration-capable framework in which scan execution can move from edge to cloud when local resources saturate. Under high I/O load, collaborative mode reduces latency by **32.5% on average**; when CPU utilization exceeds **85%**, it reduces latency by **52.1% on average**; under low network bandwidth, the paper summarizes the average effect as **-11.1%** [2508.15285].

In computer vision, **CrowdQuery** becomes the name of a density-guided module for transformer-based detection in crowded scenes. The method predicts an object-density map, embeds it, and injects it into the decoder to create density-guided queries. On STCrowd, **CQ2D** with ResNet-50 reports **AP = 91.4** and **MR\(^ {-2}\) = 33.2**, while **CQ3D** with ResNet-50 reports **mAP = 52.7**, **AR\(_0\) = 74.4**, **AR\(_1\) = 65.7**, and **AR\(_2\) = 57.6** [2509.08738].

A nearby but different acronymic pattern appears in conversational search. **AGENT-CQ** uses “CQ” for **clarifying questions**, not CrowdQuery. Its pipeline combines LLM-based clarifying-question generation with **CrowdLLM**, an evaluation stage that simulates crowd judgments using **three GPT-4 instances** and assesses outputs over multiple quality dimensions [2410.19692].

The cumulative implication is that “CrowdQuery (CQ)” has become a strongly context-dependent label. In schema matching it names a probabilistic crowdsourcing framework; in ontology engineering it abbreviates competency questions; in logic it abbreviates conjunctive queries; in systems it can mean collaborative queries; and in vision it names a specific decoder-guidance mechanism. Accurate interpretation therefore depends less on the initials themselves than on the surrounding research domain and the paper-specific formalism.

Source: https://www.emergentmind.com/topics/crowdquery-cq