GP-Selector: Bridging the Gap Between Task Creation and Intelligent Participant Selection in MCS

TL;DR

Mobile Crowdsourcing (MCS) often struggles with two extremes: tasks are either too hard to create for non-programmers or sent to participants who have zero interest in completing them. GP-Selector introduces a unified framework that simplifies task creation through ontology modeling and optimizes delivery via a two-phase "Qualification + Willingness" selection engine. It achieves high precision (0.81+) in predicting user acceptance while remaining accessible to end-users.

Problem & Motivation: The "Qualification vs. Willingness" Gap

In traditional MCS, selection is usually one-sided. A task creator sets local constraints (e.g., "I need someone in Central Park with a camera"), and the system pushes the task. However, this ignores the human element:

1. The Skill Barrier: Most platforms require professional coding to define complex sensing logic.
2. The Fatigue Factor: Users get overwhelmed by irrelevant tasks, leading to "notification blindness."
3. The Acceptance Mystery: Even if a user can do a task, will they? Factors like reward levels, privacy sensitivity, and current workload are rarely modeled.

Methodology: The GP-Selector Architecture

The framework operates across two distinct lifecycles: Task Creation Time and Runtime Selection.

1. Task Creation: Ontology for All

GP-Selector uses a "dual-track" approach for development:

• For End-Users: A simplified mobile UI where parameters like sensing scale, time-to-live, and incentive are set via toggles and maps.
• For Developers: A Core Ontology Model (COMMCS) that models entities (Task, Creator, Participant) and their relationships. This allows for "Software Reuse"—developers can extend the ontology and use QualifyScript (an XML-based language) to chain filters together.

2. Runtime: The Two-Phase Filter

Once a task is live, GP-Selector triggers a pipeline:

• Phase 1: Qualification-Based Selection: Uses a "Pipe-and-Filter" model. It executes filters (e.g., Location -> Battery -> Sensor Check) in an optimized order—prioritizing static/less-private data to save energy.
• Phase 2: Willingness-Based Selection: This is the "secret sauce." It extracts features (Incentive, Interest, Privacy Sensitivity, Workload) and passes them to an ensemble of SVM, Logistic Regression, and Decision Trees. Using majority voting, it identifies users most likely to say "Yes."

Experiments & Results

The authors validated the system through three lenses:

1. Usability

In a study with 12 non-programmers, users successfully created tasks like "Manhole Cover Monitoring" in under 6 minutes. The System Usability Scale (SUS) score of 80.6 places the tool in the "Excellent" category.

2. Precision in Selection

The willingness model was tested using a dataset of 7,875 historical cases. The results confirmed that the personalized model (trained on an individual's history) significantly outperforms random selection and single-classifier models.

3. Feature Impact

The study showed a linear improvement in precision as more participant-side features were added. Specifically, moving from just "Incentive" to a full suite (Incentive + Interest + Privacy + Workload) boosted precision from ~0.54 to 0.819.

Critical Analysis & Conclusion

Takeaway: GP-Selector is a robust "Middleware" solution. By abstracting the complexity of sensor access and participant modeling into a generic framework, it allows MCS to scale beyond niche apps into general-purpose utility platforms.

Limitations:

• Feature Breadth: The current model uses a limited set of 4 features. Real-world willingness might depend on more ephemeral factors like weather or phone movement (Activity Recognition).
• Cold Start: While the "Generic Model" helps new users, its performance is noticeably lower than personalized models, suggesting a need for better transfer learning.

Future Outlook: As we move toward the "Internet of Everything," frameworks like GP-Selector will likely evolve to include Online Learning, where the model updates in real-time as users accept or reject tasks in the field.