LogicCrowd: Extending Prolog for the Era of Mobile P2P Crowdsourcing

TL;DR

LogicCrowd is a framework that brings the elegance of declarative programming to the chaos of mobile crowdsourcing. By extending Prolog with unique crowd-query operators, it allows developers to treat a network of humans like a distributed database. It introduces robust P2P routing mechanisms and energy-aware "Power-to-Live" protocols to ensure that mobile devices don't exhaust their batteries while processing multi-hop social queries.

Background: Why Programming the "Crowd" is Hard

Most crowdsourcing systems (like Amazon Mechanical Turk) rely on central servers. However, in mobile scenarios—like asking people at a concert for the nearest exit—centralized servers lack local relevance and proximity. Moving to a Mobile Peer-to-Peer (M-P2P) model solves this but introduces three major headaches:

1. Complexity: Writing code to handle multi-hop network discovery is tedious.
2. Energy: Constant broadcasting drains batteries.
3. Asynchrony: Humans don't reply in milliseconds; the code must handle long delays without crashing.

Methodology: Logic Programming as the Solution

The researchers chose Prolog because its declarative nature is perfect for querying knowledge—whether that knowledge resides in a local database or in a person's brain nearby.

1. The Crowd Predicate

LogicCrowd introduces a new syntax for human tasks: crowd_KW ? (Answer) # [Conditions]

For example, nice?(Rest)#[askto([bluetooth])] tells the system: "Ask the crowd via Bluetooth which restaurant is nice, and unify the result with the variable Rest."

2. Multi-Hop and Peer Control

To scale beyond immediate neighbors, the authors propose two models:

• Decentralized (*Task): The task is propagated like a virus through the network. To prevent "infinite loops," each task has an ID, and peers only forward tasks they haven't seen before.
• Centralized (PeerID*Task): The originating user maintains control, explicitly querying friends of friends in a depth-first search manner.

(The formula for calculating TTL to manage query lifetimes across peers)

3. Staying Alive: PTL and TTL

To protect mobile hardware, the system uses:

• Power-to-Live (PTL): Before forwarding a task, the device calculates if it has enough "energy budget" (based on a user-defined percentage of current battery). If Ebroadcast > PTL, the task is dropped.
• Time-to-Live (TTL): A countdown timer that ensures queries expire after a certain window, preventing the network from being clogged with stale requests.

Experiments and Real-World Scenarios

The authors implemented a prototype connecting tuProlog with Android. They tested two fascinating use cases:

• Comparison Tasks: Asking the crowd to compare two camera photos. They introduced a "Threshold" operator [10]*best?(Ans), which automatically returns the result as soon as 10 people agree, rather than waiting for an expiry timer.
• Geo-Boundary Finding: Using the crowd's GPS coordinates to map the physical boundaries of an event (like a music festival) and finding the nearest exit gate via peer responses.

(Left: Initiating the goal; Middle: What the crowd sees; Right: Visualizing the crowd-sourced results on a map)

Deep Insight & Conclusion

LogicCrowd demonstrates that the Inductive Bias of logic programming—treating everything as a search for a proof—is remarkably well-suited for crowdsourcing. By abstracting the "crowd" as just another fact-finding mechanism, it hides the complexity of P2P networking from the developer.

Takeaway: Future mobile applications will likely move away from "app-silos" toward these kinds of decentralized, declarative "task-sharing" layers where the distinction between a local database query and a social query becomes invisible.

Limitations: The paper acknowledges that while transparency improves reliability, it increases the processing load on the "origin" device. Furthermore, security and malicious responses (crowd-gaming) remain areas for future exploration.