Search arXivSearch

arXiv · 2407.11575

On the Need for Configurable Travel Recommender Systems: A Systematic Mapping Study

Abstract

Travel Recommender Systems TRSs have been proposed to ease the burden of choice in the travel domain by providing valuable suggestions based on user preferences Despite the broad similarities in functionalities and data provided by TRSs these systems are significantly influenced by the diverse and heterogeneous contexts in which they operate This plays a crucial role in determining the accuracy and appropriateness of the travel recommendations they deliver For instance in contexts like smart cities and natural parks diverse runtime informationsuch as traffic conditions and trail status respectivelyshould be utilized to ensure the delivery of pertinent recommendations aligned with user preferences within the specific context However there is a trend to build TRSs from scratch for different contexts rather than supporting developers with configuration approaches that promote reuse minimize errors and accelerate timetomarket To illustrate this gap in this paper we conduct a systematic mapping study to examine the extent to which existing TRSs are configurable for different contexts The conducted analysis reveals the lack of configuration support assisting TRSs providers in developing TRSs closely tied to their operational context Our findings shed light on uncovered challenges in the domain thus fostering future research focused on providing new methodologies enabling providers to handle TRSs configurations

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Rickson Simioni Pereira, Claudio Di Sipio, Martina De Sanctis, Ludovico Iovino. 2024-07-16. On the Need for Configurable Travel Recommender Systems: A Systematic Mapping Study. https://arxiv.org/abs/2407.11575

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Energy-Efficient Code Generation Using Large Language Models: A Systematic Literature Review

Large Language Models (LLMs) are increasingly used in software engineering for code generation, completion, translation, and repair. While substantial research has examined the energy consumption and environmental impact of LLM training and inference, considerably less attention has been given to the energy efficiency of the code produced by these models. Existing studies are fragmented across different models, programming tasks, benchmarks, hardware platforms, and measurement methods, making it difficult to draw consistent conclusions about the energy efficiency of LLM-generated code. No systematic synthesis currently consolidates these findings or identifies common trends, gaps, and methodological inconsistencies. To address this gap, we conduct a systematic literature review of existing empirical studies on the energy efficiency of LLM-generated code. We examine the extent to which LLMs generate energy-efficient code, the metrics used for evaluation, the benchmarks, datasets, and measurement tools employed, and the influence of prompting and fine-tuning strategies. Our findings show that the current evidence remains limited and highly heterogeneous. Most studies rely on conventional software-efficiency metrics and existing programming or code-generation benchmarks rather than evaluation methods specifically designed for LLM-generated code. The reported energy-efficiency outcomes are strongly dependent on the evaluated model, task, benchmark, and experimental configuration, and no single prompting strategy consistently improves energy efficiency across settings. We further find limited investigation of small language models, energy-aware fine-tuning, diverse programming languages, real-world software domains, and direct hardware-based energy measurement. Overall, the review highlights the lack of standardized evaluation practices and dedicated energy-efficiency benchmarks.

cs.SE

Where Accountability Lives: Mapping Human Responsibility to Workflow Artifacts in Agentic Software Development

Coding agents author commits, open pull requests and push code in production repositories. Responsibility is settled in two layers that do not refer to each other: platform controls gating what an agent may do, and provider terms allocating responsibility for its output. Objective: Where the two layers disagree at a workflow event, and what each states there about authority, execution, verification, consequence and record. Method: A qualitative document study of 121 items archived byte-exact: documentation for four agentic coding tools, the platform controls on their output, and eighteen policy documents from seven providers, read by deductive content analysis against an a-priori system of five dimensions and nine workflow events. An independent second coder blind-recoded the verification-mechanism classification, a complete enumeration and not a sample (Cohen's kappa 0.81, n = 13, on whether a mechanism compels; 0.75, n = 12, on who performs it). Results: Cursor's terms make the user responsible for evaluating the use of any suggestion; its documentation describes a product that performs that evaluation and records it as an approval. No collected artifact records that the verification the terms make the user's duty took place. At merge two tools compel a person, one documents an agent approving below a configured risk threshold, and one only advises. Six of the fifteen mechanisms that compel a check have a default the vendor states; nine have one this study inferred. Readers who had not made them refuted five of the eight absence claims; three survived, one materially qualified. Conclusions: The terms attach duty and consequence to output as a class, the platform records events, nothing records the duty discharged. One vendor documents a product that forms the approval judgement, and the terms allocate consequence against the artifact regardless.

cs.SE

Rebuild Dossier: Mechanically-Enforced Specs for Agentic App Rebuilds, and What Model-Tier Failures Reveal

An AI agent's rebuild is only as good as the process that produced it. Prior work found that once a model is strong enough, a multi-agent rebuild pipeline loses to the simplest approach: giving the model the original code and one instruction (AgentModernize). We present rebuild-dossier, an open-source tool that locks an application's real interface - its exact inputs and outputs - before any code is written, then enforces one-test-at-a-time building through automated checks, not written instructions alone. Three results shape this evaluation, with differing amounts of evidence. First, in a small comparison, the compliant agent failed a held-back test while the rule-breaking agent passed everything - proof that a passing suite doesn't certify correctness when tests can be gamed. Second, we tested whether this beats simply giving the weaker model the source and one instruction: tied on a small app, but lost outright on a larger one where the automated check wasn't even running - pointing to the check mechanism, not interface-locking, which held up separately. Third, every claim here is checked at three levels - the agent's own report, an automated log, and the actual files produced - catching real errors, including a bug in our own logging code, that a single level would have missed. These risks reproduce on a different model and toolchain: a stronger model followed our process three times running, something the weaker model never managed. The tool is public, MIT licensed, and reproduces end to end against our own applications.

cs.SE