[IEEE Comm. Mag.] Collective Intelligence: The Missing Link in User-Driven Service Creation
NEW CONVERGED TELECOMMUNICATION APPLICATIONS FOR THE END USER
The paper proposes a framework for user-driven service creation that leverages Collective Intelligence, specifically Experience of Service Composition (ESC) and Activity Knowledge Base (AKB). By integrating distilled user experiences with activity patterns mined from Web 2.0 resources (e.g., eHow, blogs), the system enables non-expert users to compose complex, converged services using Open APIs.
TL;DR
This research addresses the "knowledge gap" that prevents ordinary users from building their own digital services. By combining Experience of Service Composition (ESC) and web-mined Activity Knowledge (AKB), the authors created a system that suggests the right Open APIs (Telecom, Web, Third-party) based on real-world human behavior patterns, rather than just technical documentation.
Field Positioning: This work bridges the gap between Semantic Web Services and Web 2.0 Social Mashups, moving from rigid, specialist-only development to an intuitive, "collective-intelligence-driven" environment.
The Problem: The Knowledge Scarcity Architecture
Despite the explosion of Open APIs (from Google Maps to Telecom messaging), creating a converged service remains a task for developers. Most Service Creation Environments (SCEs) assume the user knows:
- Which APIs exist.
- How to map a real-world goal (e.g., "Find and buy jogging shoes") into technical API calls.
- How to handle data flow between disparate providers.
Prior works relied heavily on IOPE (Input, Output, Precondition, Effect). However, if a developer didn't perfectly document a service’s "Effect," the automated system broke. This is the Knowledge Scarcity problem.
Methodology: The Dual-Engine Intelligence
The authors propose a system that doesn't just look at code; it looks at people.
1. Experience of Service Composition (ESC)
Think of this as a "Version Control" for user intent. When a user successfully connects a Map API to a Payment API, that experience is distilled into Functional Semantics. The next user with a similar goal doesn't need to start from scratch; they inherit the "collective experience" of previous creators.
2. Activity Knowledge Base (AKB)
This is the "Learning from the Web" component. By mining sites like eHow and personal blogs, the system extracts how humans naturally complete tasks.
- Insight: If the system knows that "Buying Shoes" usually involves "Comparing Prices" and "Asking Friends," it can proactively suggest a PriceCompare API even if the user didn't think of it.
Figure 1: The proposed workflow where ESC and AKB support the User-Driven Service Creation environment.
Real-World Scenario: The Shopping Journey
The paper illustrates a scenario (Mr. Kesla’s shopping trip) where the system dynamically guides a user:
- Step 1: Use Google Maps API to find malls (via ESC suggestions).
- Step 2: The AKB suggests a "ComparePrice" service because it knows "buying something" usually involves a price check.
- Step 3: Social integration (FOAF/SIOC) allows the user to trigger an "AskToFriends" composite API.
Figure 2: Statistical analysis of topic categories from eHow (left) and the resulting Activity Knowledge Model (right).
Experimental Validation & Social Extension
The authors emphasize that as the number of Web 2.0 resources grows, the coverage and depth of the knowledge base increase automatically. This creates a Self-Evolving System. By integrating with FOAF (Friend of a Friend) and SIOC (Semantically-Interlinked Online Communities), the composition results can be shared across social circles, further enriching the collective intelligence.
Critical Analysis & Future Outlook
Takeaways:
- From Data to Intent: The real breakthrough is the use of Functional Semantics—describing what a service does in human terms rather than just what data it takes.
- Domain Agnostic: By mining the web, the system scales across domains (Health, Travel, Finance) without manual rule-writing.
Limitations:
- API Trust: The paper focuses on discovery but doesn't deeply address the security/trust implications of using "third-party" APIs suggested by the web.
- Dynamic Environments: While it handles "service unavailability" via functional semantics, the real-time reconciliation of data formats between different providers remains a significant technical hurdle.
Conclusion
This paper serves as a blueprint for the "No-Code" movement before the term became mainstream. By treating the collective actions of humans on the web as a structured knowledge base, we can finally lower the barrier to digital creation, turning every smart device user into a service creator.
