Taste It! Try It!: Bridging the Gap Between Semantic Web and Real-World Mobile Recommendations
Challenges in Using Linked Data within a Social Web Recommendation Application to Semantically Annotate and Discover Venues
This paper presents "Taste It! Try It!", a semantically-enhanced mobile recommendation system that leverages Linked Data (DBpedia) and social networks (Facebook) to annotate and discover venues. The authors demonstrate a faceted-based approach for user-friendly semantic content creation on mobile devices while achieving a SOTA-level focus on the practical deployment challenges of Linked Data.
TL;DR
The "Taste It! Try It!" application is a mobile-first venue recommendation system that moves beyond simple star ratings by integrating DBpedia Linked Data and Facebook social graphs. It solves the friction of semantic data entry via a "stealthy" auto-completion mechanism and addresses the massive performance bottlenecks of public SPARQL endpoints through a custom local RDF caching strategy.
Problem & Motivation: The "Semantic Invisible" Hurdle
The Semantic Web (Web 3.0) promises a world where machines understand the nuances of our data. However, two major walls have blocked its adoption:
- The Interaction Barrier: Asking users to manually select complex RDF tags is a UX nightmare, especially on mobile.
- The Infrastructure Barrier: Public Linked Data sources (like DBpedia) are often slow, inconsistent, or offline, making real-time "federated queries" (searching across multiple databases) practically impossible for production apps.
Current SOTA recommenders often stay "trapped" in walled gardens of data. The authors of this paper argue that for Semantic Web technologies to succeed, they must be invisible to the user and robust enough to survive the unpredictability of the open web.
Methodology: The Architecture of "Taste It! Try It!"
The system utilizes a three-tier architecture: An Android client, a Facebook-integrated web front-end, and a Central Server connected to an RDF repository (INSEMTIVES platform).
1. Stealthy Semantic Annotation
Instead of forcing users to navigate complex ontologies, the application uses a faceted-based auto-completion system. As a user types a dish name, the app triggers a background SPARQL query limited to the "Food" branch of DBpedia.
- Disambiguation Logic: It calculates the Levenshtein distance (string similarity) to suggest the most likely concepts, ensuring that "Pasta" in the app maps to
http://dbpedia.org/resource/Pasta.
2. Overcoming the SPARQL "Time-Out"
Early versions of the app tried Federated Queries—asking DBpedia and the local server for info simultaneously. This failed miserably due to 30-second wait times. The authors shifted to a Local Cache Strategy:
- They downloaded massive (111GB) RDF files from DBpedia.
- They used shell scripts to extract and "prune" only the relevant concepts (Cuisines, Dishes, Venues).
- This transformed a complex global search into a lightning-fast local lookup.
Figure 1: The system architecture showing the interplay between local servers, DBpedia, and Facebook APIs.
Experiments & Results
The system was battle-tested with 180 users over two months.
- Data Yield: Over 2,200 reviews and nearly 6,000 distinct semantic links created.
- Performance Insight: The study proved that public SPARQL endpoints are currently too "immature" for direct mobile consumption. Federated queries (shown below) often hit "limit" and "offset" errors when dealing with thousands of results, requiring recursive script-based fetching to be stable.
Figure 2: The mobile UI demonstrating mapping-based search and GPS-integrated venue discovery.
Critical Analysis & Conclusion
The Good
The paper provides a refreshing "reality check" for Semantic Web researchers. It moves away from theoretical ontology design and focuses on the pragmatics of data synchronization and latency. Their approach to using social cues (Facebook expert titles) to incentivize data contribution is a clever "Human-in-the-loop" mechanism.
The Limitations
- Data Freshness: By localizing the DBpedia data to ensure speed, the app risks using "stale" data if DBpedia updates its concepts.
- Privacy Latency: The requirement to strictly follow Facebook's privacy policy (no local storage of friend lists) forced redundant API calls, creating a "secondary bottleneck" in the user experience.
Future Outlook
This work highlights that the future of Linked Data apps lies in Hybrid Data Management. Developers should treat the Semantic Web as a source of truth for modeling, but rely on localized mirrors for performance. As we move toward 2026, the integration of Large Language Models (LLMs) could potentially automate the disambiguation step that currently relies on Levenshtein distances and manual scripts.
Takeaway: Semantic richness should never come at the cost of the "back button." If it takes 30 seconds to load a restaurant, the user has already left.