An Ontology-Driven Framework for Personalised Context-Aware Running Event Recommendations

Abstract

Sport tourism has experienced significant growth within the tourism industry, driven by the increasing demand of special interest tourists to watch or participate in sports events with local sightseeing. However, the massive volume of available information related to sport events may cause challenges to existing recommendation systems, which struggle to provide tailored suggestions for these niche tourists. Therefore, this paper proposes a novel, context-aware recommender framework that utilises the ontology-driven approach with unsupervised machine learning techniques to deliver personalised event matches for running tourists. Using an ontology-driven approach, the framework establishes a knowledge base of user profiles and running events. Furthermore, K-modes clustering was also applied to categorise participants based on their event participation characteristics, while the Apriori algorithm was used to uncover hidden relationships influencing event selection. To ensure the statistical integrity of the discovered association rule, permutation testing was implemented to mitigate bias inherent in small sample sizes. By integrating refined association rules with Jena rules, the resulting prototype offers adaptive, personalised, and contextually relevant running event recommendations that evolve with shifting user preferences and trends. The effectiveness of the prototype is confirmed through rigorous validation and evaluation across various sport tourism scenarios.

1. Introduction

The rapid growth of Special Interest Tourism (SIT), driven by demand for niche leisure experiences, has led to a significant expansion of sport tourism. This involves travel for the purpose of engaging in or attending sporting events [1]. Phuket, Thailand, has emerged as a prominent sport tourism destination, consistently hosting world-class running competitions [2]. The number of running events in Thailand dramatically increased from 810 in 2017 to 1872 in 2022, with over 1800 projected for 2023 [3]. Phuket achieved success in 116,000 tourists participating in sports competitions in 2022, a substantial increase of approximately 73,350 from the previous year [4]. Events like The Laguna Phuket International Marathon (sanctioned by the Association of International Marathons and Distance Races (AIMS) and the International Association of Athletics Federations (IAAF)), and a qualifier for major marathons such as Boston and Tokyo, highlight the region’s appeal [4]. This increased specialisation in sport tourism, coupled with the considerable amount of online information, often overwhelms travellers seeking specific activities and attractions that match their interests [5,6,7,8].

Consequently, Recommender Systems (RSs) have become increasingly applied in the tourism domain as information filtering systems that manage this excess data to suggest a list of personalised and suitable products or services to tourists. It predicts an individual’s preferences and interests to provide relevant recommendations [9,10,11]. Traditional RS typically rely on either Content-Based (CB) or Collaborative Filtering (CF) to understand user preferences and make suggestions. CB approaches provide the recommendation based on the features of items that were preferred by the user in the past, whereas CF approaches provide the recommendation based on the preferences and behaviours of similar users in certain items [11,12]. Examples of CB applications to sport events are [13] for sport videos, specifically designed for large-scale events like the Olympic Games, based on a user’s audiovisual consumption data. In [14], a hybrid approach of CB with CF was proposed to provide personalised news recommendations.

However, both CF and CB recommender systems face challenges like the cold-start problem, which encounters the lack of sufficient historical data to make accurate and relevant recommendations for new users and items [12,15]. Knowledge-based (KB) approaches overcome cold-start issues by providing immediate suggestions for new users and items based on semantic descriptions and user preferences, rather than historical interactions [16,17,18]. Without a knowledge base, the system would struggle to organise and understand the complex relationships between user contexts and preferences, as highlighted in [18]. One of the possible knowledge representation approaches is to employ the semantic models, where the domain knowledge is typically structured as an ontology. The Ontology-Based (OB) approach defines the semantic data representation of sport events, enabling the utilisation of a reasoning feature for the recommendation process [19]. This allows the system to intelligently comprehend and process personalised recommendations through ontology queries with content-based filtering and social-network-based user profiles, specifically targeting a niche group of travelers. However, explicit rules from user preference analysis are still needed to enhance the system’s ability to accurately detect and understanding the user’s context.

Since the context-aware RSs address the evolution of user preferences with the context, Rule-based Ontology (RBO) has been widely cooperated with them. It offers significant benefits by establishing a structured, formal, and extensible framework for representing, reasoning about, and utilising user’s context information [20,21]. Rules derived by domain experts leverage a detailed and reasoned understanding of context, thereby enabling highly personalised recommendations and the tailored provision of suitable items or services according to user preferences. To provide the niche filtering recommendation, inference rules are explicity extracted from the ontology. Semantic Web Rule Language (SWRL) is a well-known technique used for rule extraction [21,22,23]. Some research studies use Machine Learning (ML) techniques, such as [18], which used Neuro-Fuzzy classification with a set of fuzzy rules to extract and classify the context of each customer review. However, using Supervised Learning (SL) techniques for user feedback or review analysis presents difficulties due to the high demanding and time-consuming of labelling sentiment data, which requires domain expertise. Furthermore, training Neuro-Fuzzy systems on very large, feature-rich datasets can be computationally prohibitive. As user preferences and trends usually change, Unsupervised Learning (UL), like Association Rule Mining (ARM) techniques, is an alternative way to extract the inference rules. It discovers hidden patterns and unknown rules among user preferences, contextual influencing factors, and associated events. Association rules also offer the adaptability to automatically capture evolving user preferences, popular trends, and implicit item relationships.

Therefore, this paper introduces a novel, ontology-driven framework for personalised context-aware running event recommendations. The proposed approach establishes a semantic structure within a knowledge-based ontology, aligning with the interests of sports tourists. It incorporates ontologies for running events in Thailand, previously developed in [24]. The framework integrates two primary ontologies: the User Profile Ontology, which structures specific tourist information, including sport interests and racing participation history, and the Running Event Ontology, which represents running events and tourist destinations in Phuket province. To provide personalised suggestions for running competitions that precisely match user preferences, K-modes clustering for runner competitors’ data grouping based on their event participation factors and the Apriori algorithm for association rule discovery were implemented. Furthermore, permutation testing was utilised to account for small-sample bias and verify the reliability of the discovered association rules. These refined association rules were integrated into Jena rules implemented in the prototype to demonstrate how our framework can effectively recommend suitable running events that align with the context and interests of sport tourists. The prototype’s results were compared with expected outcomes from running competitors to validate the recommendation efficiency.

2. Method

Figure 1 shows our proposed framework of context-aware recommender system for running tourists. This framework is an extended version of the capability of a Running Event Ontology Framework proposed in our previous work [24]. This framework consists of three main stages.

2.1. Stage 1: Ontology Engineering

This stage provides a set of activities for building the ontology. This starts with Preprocessing (Step 1.1) that prepares, consolidates, and cleans various data and information to be used in the development of the ontology including running competitors, running events, and event venues gathered from different sources. Then, Step 1.2 Ontology Modeling is processed to develop a structured representation of data for a recommendation system. The seven-step development process proposed by Noy and McGuinness [25] was applied to develop our ontologies. Two types of ontologies are developed: the Running Event Ontology and the User Profile Ontology. Running Event Ontology collects and organises data related to various running events, including event venues and tourist destinations associated with each running event, whereas User Profile Ontology collects and organises personal data of sport tourists, including their interests, factors influencing their participation in running events, and their past participation history. Finally, the achived ontologies are evlauated (Step 1.3: Ontology Evaluation). Two steps for ontology evaluation are performed. (1) Evaluation of Ontology Structure evaluates the ontology structure by both ontology and running competition experts. (2) Evaluation of Information Retrieval evaluates the ontology by querying data using SPARQL based on competency questions related to classes and relationships within the ontology [26]. The questions were derived from the needs of running competitors to participate in running events. Furthermore, precision and recall are calculated to measure the effectiveness of the ontology.

2.2. Stage 2: Rule Extraction

Rules Extraction is a process of deriving recommendation rules using data from sport tourists, which includes factors that influence their participation in running events. As the tourists’ data lacks predefined groups, the unsupervised learning technique is employed to categorise and classify the data. The factors influencing event selection, such as race types (e.g., Fun Run, Mini Marathon, Half Marathon), type of event (e.g., Charity, Competitive), activity Area (e.g., Natural, City), and reward (e.g., Medal, Finisher Shirt), are categorical data. Therefore, K-modes clustering [27] is chosen as the appropriate method for grouping this data. To discover patterns or relationships among these categorical factors, the Apriori algorithm [28] is specifically chosen as the most appropriate ARM method, particularly over alternatives like Numerical ARM (e.g., NiaARM [29]). The resulting association rules, then, are transformed into the recommendation rules represented in the form of Jena Rules. Our recommender system implements Jena Rule Engines to perform reasoning over data (in RDF and OWL formats) through these rules. All generated recommendation rules will be stored in a rule file, which will be utilised to infer the runner preferences to the factors of running events and ultimately recommend relevant running events.

2.3. Stage 3: Recommendation System Development

This stage develops the recommendation system after successfully producing the ontology and recommendation rules. The recommendation system starts when the user inputs their personal information, as well as the interest factors influencing the running event participation, together with their past participation history, via a web application. Then, a user profile is created from the input data and stored in the User Profile Ontology. Next, the recommendation rules are retrieved through the Jena API [30], which is a framework used for building the recommender system. This results in the classes and properties in the ontologies to be read before the inference process is performed based on the rules of the ontologies by Jena Rule Reasoning. After that, the Recommender Engine displays a list of running events that align with the preferences of the user, providing suitable recommendations based on the user’s interest factors.

3. Results and Discussion

3.1. Factors Influencing Running Competitor Participation

Table 1. Contextual Data Sources.

No.	Data Source	Description	Number of Respondents/Number of Records
1	Interview	Data obtained from interviews, covering five main questions: (1) reasons for starting to run, (2) running goals, (3) expectations from participating in running events, (4) factors influencing their decision to join different running events, and (5) preferred race type.	The sport event needs for running event selection were collected in 2019 from 10 running competitors, including 3 professional competitors and 7 general competitors.
2	Online sources	Data from various online sources, including Facebook [31], Pantip [32], WingnaiDee [33], Runlah [34], ThaiRun [35], Phuket Index [36], and TripAdvisor [37].	969 records of running event information from these online sources between 2017 and 2021 were extracted.
3	Research studies	Data from research studies [38,39,40] related to contextual recommendation factors and factors related to sports-oriented tourism and event participation.	53 factors influencing the participation of running competitors were used for the development of ontologies.
4	Questionnaires	The interests in sport-oriented tourism were collected from running competitors who had previously participated in various running events through questionnaires.	Data regarding the interest in running competitions was collected in 2021 from 39 running competitors through the questionnaire.

illustrates the contextual data gathered from various diverse sources related to running competitors, running events, and event locations. We followed a mixed-methods research design, which effectively integrates qualitative, quantitative, and expert/domain knowledge. There are four highly complementary data sources that are essential for building a robust running event recommender system. The knowledge is extracted, analysed, and enriched. The interview and questionnaire data sources are analysed into running goals, expectations, and influencing factors from competitors. This results in a set of runner profile features to be extracted. Research studies define and extract the knowledge factors that influence event participation. This enriches the analysis of online sources to indicate the feature dictionary for the running events.

The factors influencing the running event participation were identified and categorised into four main contexts as demonstrated in

Table 2. Factors influencing the participation of running competitors.

Context	Factors
User context	Personal information, including name, age, nationality User’s interestes including reward interest, race type interest, location interest, activity area interest, level of event interest, standard of event interest, price interest, start period interest, organization interest Participation history, including running event history, latest race type, travel place history
Running event context	Running event name, race type, type of event, standard of event, race day, reward, level of event, activity area, price, start period, start date, end date, age categories, cut-off time, start time, weekday
Travel place context	Travel place name, travel place type, opening time, closing time, activity, opening day, closing day
Environment context	Weather status, running event venue, province, district, location, reported date, temperature, precipitation, humidity

.

3.2. Running Event Recommendation Ontologies

The data and information from running event sources and factors influencing the participation in running events described in Table 1 and Table 2 respectively were used to model the ontologies for running event recommendation. The ontologies were developed in Protégé [41] according to 7 steps of ontology development by Noy and McGuinness [25]. We enriched the ontology structure proposed in our previous work [24] to fulfill the needs of a recommendation system. This resulted in two types of ontologies: the Running Event Ontology and the User Profile Ontology, as shown in Figure 2 and Figure 3, respectively.

Figure 2 shows the structure and relationships of the Running Event Ontology. It encompasses the information and factors related to running events. It’s composed of 7 classes, 8 object properties representing relationships between classes, and 33 data properties representing class attributes. The core class is RunningEvent, which represents general information about running events. This class has various data properties such as StandardOfEvent, TypeOfEvent, StartDate, and EndDate, indicating the running event properties, including standard, event type, start date, and end date, respectively. The RaceType class defines different running race categories, including FunRun, MiniMarathon, HalfMarathon, and Marathon. This class uses data properties such as RaceDay, StartTime, and CutOffTime to specify the date, start time, and cut-off time for each race type, respectively. Furthermore, the RunningEvent class is linked to RaceType via the hasRaceType object property, indicating the specific race types associated with a running event. The hasEventVenue object property connects RunningEvent to RunningEventVenue, signifying the venue where events are hosted. All classes and relationships of the Running Event Ontology are available at [42].

Figure 3 illustrates the structure of the User Profile Ontology, which captures diverse information about users, including personal details, factors influencing running event selection, and participation history. This ontology comprises 1 main class, 7 object properties representing relationships between classes, and 11 data properties representing class attributes. The main class is User, which represents information related to running competitors. It includes personal information through data properties such as UserAge, UserSex, and Nationality. Additionally, it details factors of interest in running competitions, including StandardOfEventInterest, ActivityAreaInterest, StartPeriodInterest, and RewardInterest. The User class also defines various relationships. For instance, the hasRaceTypeInterest object property links the User class to RaceType, indicating the specific race types a user is interested in. Similarly, the hasRunningEventHistory object property connects the User class to RunningEvent, representing the user’s past participation in running events. All classes and relationships within the User Profile Ontology are accessible at [42].

To ensure the quality and effectiveness of our formally represented knowledge, the overall structure and organisation of the developed ontologies was evaluated. The evaluation was conducted with the experts, consisting of three experts in the field of ontology and two experts in the field of running events. These experts assessed the ontologies based on their expertise and knowledge in their respective domains, focusing on questions concerning the coherence and consistency of classes, object properties, and data properties. They also reviewed the representation of relationships between different classes and properties, as well as the ontology’s modularity and reusability. A Likert scale [43] was employed to establish agreement levels for each question: Strongly Agree (5), Agree (4), Neutral (3), Disagree (2), and Strongly Disagree (1).

Table 3. Evaluation of the ontology structure result.

Ontology	Overall Mean	Overall S.D.	Levels of Agreement
Running Event Ontology	3.6	1.11	Agree
User Profile Ontology	3.68	1.02	Agree

presents the evaluation results. Both the Running Event Ontology and the Profile Ontology have appropriate structures, receiving average overall agreement levels of 3.6 and 3.68, respectively, indicating an “Agree” level. Following this evaluation, we incorporated expert recommendations and suggestions to refine and optimise the ontology structures for their use within the recommender system.

Furthermore, an information retrieval evaluation was conducted to validate the accuracy and precision of our developed ontology. The competency questions regarding the semantic in the ontology were formulated for this purposed [26]. 17 competency questions, derived from running competitors’ expectations, were formulated to assess the semantic content of the ontology. An example of these competency questions is shown in

Table 4. Example of competency questions.

Questions	Precision	Recall
1. Which marathon running events are available?	0.2	1
2. Which running events were organised in 2019 that involved a marathon type?	0.2	1
3. Which running events award medal prizes?	1	0.6
4. Which running events are organised by Laguna?	1	1
5. Which charitable running events offer the Mini Marathon category?	1	1
.....	....	....
Overall	0.91	0.98

, with all questions and their analysis results available on the system website [42]. To facilitate the information retrieval evaluation within the ontologies, all formulated questions were converted into SPARQL queries. The computation metrics of precision and recall was adopted from [44] as $\mathrm{Precision}={\displaystyle \frac{TP}{TP+FP}}$ and $\mathrm{Recall}={\displaystyle \frac{TP}{TP+FN}}$ where TP is retrieved information and relevant to the question, FP is retrieved information but not relevant to the question and FN is the information cannot be retrieved but relevant to the question.

Out of 17 competency questions, only 3 yielded very low precision or recall, indicating areas for improvement. For instance, in question 2, SPARQL query broadly returned all running events containing “Marathon” word such as “Mini Marathon” and “Half Marathon”. This led to a higher number of FP than TP, resulting in a very low precision of 0.2. Similarly, considering question 3, SPARQL query failed to retrieve a running event that should have awarded a medal prize, causing a low recall of 0.6. Despite these specific instances, the overall results demonstrate high performance. The average precision across all questions was 0.91, and the average recall was 0.98. This confirms the ontology’s strong information retrieval capabilities, showcasing its high accuracy and effectiveness in retrieving relevant information.

3.3. Recommendation Rules

3.3.1. Rule Extraction

After the ontologies were developed, the semantic rules were extracted to enable context-specific running event recommendations for individual competitors. We utilised a dataset from data source No. 4 in Table 1, regarding interest factors from 39 running competitors influencing event participation. From this dataset, 10 key factors, including location interest, preferred race type, event type, registration fee, organization, activity area, event standard, event level, start period, and event rewards, were extracted to formulate these recommendation rules. The K-modes clustering technique [27] was performed prior to rule creation. As depicted in Figure 4, the Elbows point at K = 4 was selected as the optimal number of clusters, where the clusters began to flatten and decrease. This segmentation resulted in the interest factors being grouped into four distinct clusters, each with unique characteristics, as detailed in

Table 5. Group of running competitors from K-modes clustering.

Group	Factor
1	Race Type = “Half Marathon”, Type of Event = “Competitive”, Price = “Average”, Organization = “Bangkok Airways”, Standard of event = “Standard”, Level of event = “International”, Start period = “Morning”, Reward = “Finisher Shirt”
2	Location interest = “Mueang Phuket District”, Race type = “Mini Marathon”, Type of event = “Charity”, Price = “Average”, Activity area = “Natural”, Level of event = “Local”, Start period = “Morning”, Reward = “Medal”
3	Race type = “Fun Run”, Type of event = “Charity”, Price = “Economy”, Activity area = “Natural”, Start period = “Morning”
4	Location interest = “Mueang Phuket District”, Race type = “Fun Run”, Type of event = “Competitive”, Price = “Average”, Activity area = “Natural”, Standard of event = “Standard”, Start period = Morning”, Reward = “Medal”

.

After obtaining the four data clusters, we proceeded to find associations between each factor using the association data mining technique. The Apriori algorithm [28] was applied to the dataset to discover hidden meaningful relationships among the factors. We set a minimum support (supp.) threshold of 0.2 (20%) and a minimum confidence (conf.) threshold of 0.8 (80%). This ensures that the generated rules can be used effectively to recommend running events that are relevant to the running competitor’s interests and reduce redundant rules that may not be applicable. A total of 83 association rules were discovered as some examples of the rules are shown in

Table 6. Examples of association rules.

Assc. Rule #	LSH	RHS	Supp.	Conf.	Lift
A1	{RaceType = Half Marathon}	{Price = Average}	0.23	1.00	1.49
A11	{Price = Average, StandardOfEvent =standard}	{StartPeriod = morning}	0.54	1.00	1.17
A28	{TypeOfEvent = competitive}	{StartPeriod = morning}	0.45	0.98	1.15
A43	{StandardOfEvent = standard}	{StartPeriod = morning}	0.60	0.95	1.11
A83	{Price = Economy}	{ActivityArea = natural}	0.25	0.80	1.48

. All association rules are available at [42].

The associations and relationships among factors in the rule are explained in terms of LHS => RHS. LHS is the left-hand side item demonstrating an antecedent that possibly causes a consequent represented in the RHS (right-hand side) with a support and confidence ratio. Rule A1, for example, means that if a running competitor chooses the “Half Marathon” race type, he also chooses the race type that has the average price (668–934 Baht) with a minimum support of 23% and minimum confidence of 100%. The other example is association rule A28, meaning that if a running competitor selects the “Competitive” running event, he also chooses the event arranging the start period in the “morning” with a minimum support of 45% and minimum confidence of 98%.

3.3.2. Rule Robustness and Validation

Since the Apriori algorithm relies on statistical significance, it requires a high volume of data to distinguish genuine patterns from stochastic noise. Consequently, rules derived from a small sample size (n = 39) may reflect sample-specific coincidences rather than generalisable trends. To mitigate this small-N bias and ensure robust behavioural insights, permutation testing was employed [45].

As a non-parametric method, permutation testing evaluates the significance of machine learning predictions by providing a guarantee against false discoveries [46,47]. The procedure maintains the observed features while randomly shuffling the target labels to decouple any inherent relationships. By retraining the model on this permuted data over a certain number of iterations (e.g., 1000 times), a null distribution is established. The original model’s accuracy is deemed statistically significant as a p-value if it exceeds the 95th percentile of the null distribution ($\alpha =0.05$), indicating a non-random association.

To assess the significance of the discovered rule, p-values were calculated via a permutation-based resampling procedure. To ensure a rigorous statistical filter, we conducted a 10,000-iteration shuffle for the resampling procedure. The Lift value, which quantifies the likelihood of the consequent given the antecedent relative to its marginal frequencies, was used as the test statistic for each of the 83 rules. By independently shuffling features within the dataset (n = 39 competitors; 133 entries), the marginal frequencies of individual attributes were preserved while row-level associations were systematically decoupled to generate a null distribution. The Apriori algorithm was run on this shuffled dataset using the same threshold and generated the Lift value, before calculating p-value.

The p-value of each rule represents the proportion of permutations where the shuffled Lift exceeded or equaled the observed Lift as $p={\displaystyle \frac{count({\mathrm{Lift}}_{\mathrm{permuted}}\ge {\mathrm{Lift}}_{\mathrm{observed}})}{{\mathrm{N}}_{\mathrm{permutations}}}}$ [48]. Since multiple hypotheses are being tested simultaneously, a Bonferroni-corrected alpha [49] was applied, adjusting the significance threshold to $\alpha =0.0006$ ($0.05/83$). Rules yielding $\mathit{p}<0.0006$ are classified as statistically significant signals, indicating associations substantially stronger than those expected by random chance. Conversely, rules with $p\ge 0.05$ are categorised as noise, likely arising from sample-specific coincidences within the small-N distribution.

Table 7. Significance Distribution Results.

Category	#Rules	Interpretation
Very Strong ($p<0.0006$)	62	Reliable Behavioural Core
Suggestive ($0.0006\le p<0.05$)	11	Potential Trends
Likely Noise ($p\ge 0.05$)	10	Spurious Result

presents the results of the significance distribution analysis, which successfully distinguishes robust behavioral patterns from stochastic noise. The rules are categorised into three distinct tiers: Very Strong, Suggestive, and Likely Noise. We retained the 62 rules (74.7%) classified as very strong evidence due to their high statistical significance (p < 0.0006) and superior average Lift (1.49), representing genuine preferences rather than random associations. The suggestive evidence category ($0.0006\le \mathit{p}<0.50$), comprising 13.3% of the rules, indicates potential associations (mean Lift = 1.18). To maintain recommendation coverage while ensuring rigor, we selectively retained rules at the lower p-value bound of this range but discarded three rules approaching the 0.05 noise floor to mitigate Type I errors. This occurred primarily where RHS dominance or low marginal utility was observed, particularly in location-specific or environmental factor combinations, such as “Natural” and “Mueang Phuket”, where limited sample sizes reduced p-value robustness. Finally, 10 rules (12.0%) categorised as likely noise were discarded. These exhibited p-values ranging from 0.05 to 0.65 and Lift values near 1.0, indicating statistical independence between attributes, such as the lack of correlation between a “Morning Start” preference and “Finisher Shirt” receipt. In summary, the validation process yielded 70 statistically significant rules, representing 84.3% of the initial candidate set (83 rules).

3.3.3. Jena Inference Rules

The discovered association rules were converted into the semantic rules in the form of Jena Inference Rules. Rule Markup Language (RuleML) was used to create the rules in Jena Inference Rule format. RuleML consists of the condition part (condition) and the consequent part (action), separated by the symbol “->,” indicating the division between the condition and the consequent parts. All transformed recommendation rules were stored in a rule file.

Table 8. Examples of recommendation rule.

Jena Rule#	Jena Rule	Conf.	Assc. Rule#
J1	[Jena1: (?re run:hasRaceType ?racetype) (?racetype run:RaceTypeName “Half Marathon”) (?racetype run:Price “Average”) (?User run:hasRaceTypeInterest ?RaceTypeIn) (?RaceTypeIn run:RaceTypeName “Half Marathon”) (?User run:EventPriceInterest “Average”) -> (?User run:hasRecommend ?re) (?re run:confidence “100”) ]	100%	A1
J10	[Jena10: (?re run:hasRaceType ?racetype) (?racetype run:Price “Average”) (?User run:EventPriceInterest “Average”) (?re run:StandardOfEvent “StandardEvent”) (?User run:StandardEventInterest “StandardEvent”) (?racetype run:StartPeriod “Morning”) (?User run:StartPeriodInterest “Morning”) -> (?User run:hasRecommend ?re) (?re run:confidence “100”) ]	100%	A11, A63, A76
J19	[Jena19: (?re run:TypeOfEvent “CompetitiveEvent”) (?User run:TypeOfEventInterest “CompetitiveEvent”) (?re run:hasRaceType ?racetype) (?racetype run:StartPeriod “Morning”) (?User run:StartPeriodInterest “Morning”) -> (?User run:hasRecommend ?re) (?re run:confidence “98”) ]	98%	A28
J24	[Jena24: (?re run:StandardOfEvent “StandardEvent”) (?User run:StandardEventInterest “StandardEvent”) (?re run:hasRaceType ?racetype) (?racetype run:StartPeriod “Morning”) (?User run:StartPeriodInterest “Morning”) -> (?User run:hasRecommend ?re) (?re run:confidence “95”) ]	95%	A43
J47	[Jena47: (?re run:hasRaceType ?racetype) (?racetype run:Price “Economy”) (?User run:EventPriceInterest “Economy”) (?re run:hasRaceType ?racetype) (?racetype run:ActivityArea “Natural”) (?User run:ActivityAreaInterest “Natural”) -> (?User run:hasRecommend ?re) (?re run:confidence “80”) ]	80%	A83

presents examples of the recommendation rules. All Jena inference rules are available at [42].

Considering Jena rule J1 that was transformed from association rule A1, for instance, this rule supports the case that if the running event has a race type as “HalfMarathon” and has a price as “Average” (668–934 Baht), the user will receive a recommendation for the running events with a confidence level of 100%. Rule J19, a Jena rule of association rule A28, is the other example, which will recommend the running event with a confidence level of 98% if that running event has a type of event as “CompetitiveEvent” and has a start period as “morning”.

3.4. Recommendation Prototype Development

All functionalities for the recommendation system were implemented as web services, to provide standard information exchange mechanisms. Six services were implemented using Spring Boot 3.1.7 [50] as shown in

Table 9. Recommendation Web Services.

Service Name	Description
getAllEvents	This service is used to retrieve all running events.
getEvents	This service is to search for the specific event commanded by users.
getRecommendEvent	This service is to recommend the specific event based on the user profile.
getUserProfile	This service is to retrieve the user profile and preferences.
setUserProfle	This service is to record user profile and preferences.
auth	This service is for user authentication.

. They cooperate with a Recommendation Engine to perform complex calculations. This engine utilises Apache Jena APIs, a Java library, to establish connections between the application and the ontologies with the recommendation rules. Jena Rule Engines were implemented to extract these rules, thereby facilitating the inference process from classes and instances encoded in Web Ontology Language (OWL) and RDF Schema (RDFS) formats.

To facilitate the recommendation mechanism, we developed a web application enabling user interfaces for inputting data and visualising recommended information. Figure 5 illustrates an example of this web application at the presentation layer. Figure 5a displays the user profile creation screen, which comprises three sections: (1) Personal information, (2) Running event history which collects the past running events and the type of running events that users used to participated in, (3) Factors of interest that provides 10 factors influencing users to participate in a running event including location (as in district), race type, type of event, price, orgainzation, activity area, standard of event, level of event, start period and reward.

After the user profile is created, the Recommendation Engine utilises the Jena API’s inference rule function to apply semantic rules to the users’ instance. This process generates and returns a list of potential running events via the web services. The results are then displayed on the web application screen, as shown in Figure 5b, presenting a list of recommended running events along writh their confidence scores derived from the recommendation rules. Figure 5c further enhances this by showing detailed information for a selected recommended event, highlighting the matching factors between the user’s preferences and the event’s attributes.

3.5. Prototype Validation and Evaluation

To validate the accuracy and correctness of the developed prototype, the realistic scenarios from 10 interviewed running competitors were conducted from data source No. 1 in Table 1. For each competitor, we created a profile based on their chosen factors and event participation history. We also designed a set of running event recommendations that reflected what these selected competitors expected. These expected event listings then were compared against the event recommendations generated by the prototype from the corresponding user profiles. For evaluation purposes, Precision, Recall, and F-measure metrics were used. The computation were adapted from [44] as $\mathrm{Precision}={\displaystyle \frac{\left|\right\{ExpectedResult\}\cap \{PrototypeResult\left\}\right|}{\left|\right\{PrototypeResult\left\}\right|}}\times 100$, $\mathrm{Recall}={\displaystyle \frac{\left|\right\{ExpectedResult\}\cap \{PrototypeResult\left\}\right|}{\left|\right\{ExpectedResult\left\}\right|}}\times 100$ and $\mathrm{F-measure}={\displaystyle \frac{2\times Precision\times Recall}{Precision+Recall}}$. The factors and event participation history of the 10 competitors for the evaluation are shown in

Table 10. Factors and event participation history of the 10 competitors.

Competitor#	Factor
R1	Race type interest = “Half Marathon”, Price = “Average”, Organization = “Laguna Phuket”, Standard of event = “Standard”, Level of event = “International”, Reward = “Finisher Shirt”, History = “Phukethon 2019”
R2	Location interest = “Mueang Phuket District”, Race type interest = “Mini Marathon”, Organization = “Bangkok Airways”, Activity area = “Natural”, Level of event = “International”, Start period = “Morning”, Reward = “Medal”, History = “Phukethon 2019”
R3	Race type interest = “Fun run”, Price = “Average”, Activity area = “Natural”, Start period = “Morning”
R4	Race type interest = “Half Marathon”, Type of event = “Competitive”, Price = “Average”, Standard of event = “Standard”, Start period = “Morning”, Reward = “Medal”
R5	Race type interest = “Fun run”, Type of event = “Charity”, Price = “Economy”, Activity area = “Natural”, Start period = “Morning”, Reward = “Finisher Shirt”, History = “Run For Life”
R6	Race type interest = “Half Marathon”, Type of event = “Charity”, Price = “Average”, Reward = “Finisher Shirt”
R7	Location interest = “Mueang Phuket District”, Race type interest = “Half Marathon”, Activity area = “Natural”, Reward = “Medal”
R8	Location interest = “Mueang Phuket District”, Race type interest = “Mini Marathon”, Standard of event = “Standard”, Level of event = “International”, Start period = “Evening”
R9	Race type interest = “Half Marathon”, Type of event = “Competitive”, Price = “Average”, Standard of event = “Standard”, Reward = “Medal”
R10	Race type interest = “Fun run”, Activity area = “Natural”, Standard of event = “Standard”, Level of event = “International”

.

The evaluation was conducted by comparing the event recommendations generated by the prototype with the expected results anticipated by the running competitors. Figure 6 presents the evaluation results of the prototype. The results show that the prototype’s recommendations are consistent with the anticipated results, with an average precision of 83%, an average recall of 95%, and a resulting average F-measure of 86%. We discovered that the prototype result perfectly matched the expected data (100% of precision and recall), indicating high reliability in R6, R8, and R10. However, we have discovered that in some cases, the number of running events recommended by the prototype is more than the expected result (running competitor). For instance, in R2, only 7 of 13 recommended running events by the prototype were matched with the designed expected events. This leads the precision value to be low (54%). This is because the recommendation rules of the prototype predicted the factors arising from the association rules that possibly have the opportunity to be selected by running competitors in the future. This, therefore, resulted in additional running events being able to be considered as interesting choices for the competitors. Furthermore, considering R5, all 4 recommended running events by the prototype were matched with the 5 of expected running events. This results in low recall (80%). Similarly, for R7, the expected event count exceeded the prototype’s recommendations by two. This limitation is caused by the prototype’s recommendation rules, which did not adequately cover less frequent factors like charity-type running events that did not frequently appear in the most famous association rules. To improve this, we need to enrich user preferences by asking about their satisfaction with recommendation diversity and coverage of their interests.

Furthermore, to ensure that the recommendation rules represented genuine behavioral patterns, we compared the prototype performance using 83 initial rules versus 70 validated rules through permutation testing, as illustrated in Figure 7. As shown in Figure 7a, refining the rule set significantly improved F-measure scores for several competitors, most notably R3 (increasing from 50% to 75%), R4 (57% to 71%), and R5 (50% to 89%). Performance for the remaining competitors stayed consistently high, with R6, R8, and R10 achieving perfect 100% scores. Considering the aggregate metrics of Figure 7b, the validation process substantially increased average precision from 72% to 83%. This indicates that the refined rules effectively filter irrelevant recommendations without reducing recall, which remained stable at 95%. Consequently, the overall F-measure, representing the harmonic mean of precision and recall, improved from 78% to 86%. This can confirm that the refined rule set provides a more accurate and robust representation of competitor behaviour.

Finally, the prototype performance was evaluated. Figure 8 demonstrates the evaluation results measuring the semantic reasoning execution time against input (factor parameters) and output (recommended events) complexity across 10 distinct user profiles. To ensure accuracy, we ran the experiment three times for each user profile and calculated the average execution time (seconds). The overall execution time for semantic inference through the Jena engine was 0.382 s (SD = 0.043s), with the maximum reasoning time of 0.446s. Furthermore, a correlation analysis reveals that this computation time is independent of the user’s input and output complexity. For example, R3 submitted only 4 parameters, and the system processed this in 0.316 s. Conversely, R2 and R4 submitted a highly complex profile with 7 parameters; the system processed their requests in 0.394 and 0.344 s, respectively. Similarly, when retrieving a high set of only 2 events for R6, the system processed 0.383 s. Compared with 13 event retrieval for R2, the system processed in the same time (0.394 s). The result confirms that our proposed framework is highly optimised for real-time applications.

3.6. Lesson Learned and Discussion

3.6.1. Comparative Baseline Evaluation

To empirically validate the contribution of the proposed framework, a comparative evaluation was conducted against two baselines: a popularity-based method and a pure association rule-based method (Apriori). We discovered that the popularity-based baseline successfully achieved 100% recommendation coverage, as it consistently resulted in the highest-frequency events (e.g., standard morning marathons) for every query. However, it is limited to providing the personalisation required for niche sport tourism.

On the other hand, the pure rule-based approach (Apriori only) demonstrated high precision for the majority of behaviours. For example, it effectively recommended events for typical competitors preferring “morning” start periods and “international” level events, as these features frequently co-occurred and surpassed the 0.20 minimum support threshold. However, this method shows a weakness regarding niche sport tourists. Due to frequency bias, minority rules were pruned during mining to prevent overfitting. This results in a significant drop in coverage for edge-case users.

Our proposed framework outperformed both baselines by effectively utilising semantic reasoning to resolve the trade-off between personalisation and coverage. For standard profiles, it used the high-confidence Apriori rules to maintain baseline precision. In niche scenarios, the proposed framework invoked an ontology-based knowledge base. For instance, the semantic architecture links the Running Event class to the Race Type class (and its subclases, e.g., Marathon, Fun Run via the hasRaceType object property. Finally, the Jena rules successfully executed structural and semantic matching between the user’s profile and the event characteristics, ensuring continuous recommendation coverage.

3.6.2. Comparison with Existing KB Approaches

This section highlights the benefits of our proposed approach over benchmark and other KB methods, evaluated across four criteria, including Method, ML Type, Rule Type, and Context-Awareness, as demonstrated in

Table 11. Comparison analysis of the proposed approach with other KB approaches.

References	Method	ML Type	Rule Type	Context-Awareness	Domain
Proposed approach	RBO	UL (K-Mode clustering, Apriori association mining)	Association Rules. Jena Rules	Runner’s preferences, participation history, and factors influencing participation in running events	Running events
[18]	RBO	SL (Neuro-Fuzzy classification)	Fuzzy Rules	Context of customer reviews	Online shopping
[19]	OB	UL (K-Means, Birch, Agglomerative clustering)	SPARQL queries	-	Sport Events
[20]	RBO	-	Jena rules	Building object, time, weather, and temperature	Building Energy Management
[22]	RBO	-	SWRL Rules	Guest preferences, room features, and potentially external factors.	Hotel room personalisation
[51]	RB	SL (ZeroR, OneR (One Rule))	Not Specified	-	Football betting results

. Firstly, knowledge-based ontologies help to reduce data redundancy and identify specific contextual needs of tourists. In addition, RBOs strengthen knowledge representation by integrating rule-based reasoning for inference and decision-making. This significantly enhances the accuracy and explainability RS through explicitly encoded decision logic. When applied to Context-Aware systems, RBOs provide granular context modeling, dynamic adaptation, and deep personalisation [18,20,22]. Our RS evaluation has confirmed that the proposed approach delivers highly tailored recommendations that precisely align with user preferences. In contrast to the work of [19], where recommendations were derived through ontology queries (SPARQL) without explicit rules, our approach avoids limitations in precisely detecting and comprehending user context due to a lack of comprehensive user preference analysis.

Furthermore, the adoption of ML offers a significant advantage by organizing and categorizing vast amounts of domain (e.g., Online shopping [18] and sport event [19]) and user data. The application of unsupervised clustering groups running competitors based on their event participation factors, which is similar to [19]. Together with the Apriori algorithm, this results in the recommendation rule specifically for more personalised and appropriate running event recommendations to be discovered. We also found that these rules reveal hidden, meaningful relationships among factors influencing participation. This approach overcomes the limitations of deriving SWRL rules solely from expert knowledge, domain policies, or regulations (in [22]), which often fail to uncover unforeseen patterns and correlations in user behavior or contextual dynamics. Furthermore, unlike supervised learning methods such as Neuro-Fuzzy classification (in [18]), ZeroR and OneR (in [51]), our unsupervised approach avoids the challenges of time-consuming and expertise-demanding sentiment data labelling and computationally expensive training on large datasets.

Finally, the prototype’s Jena rules, derived from association rules, enhance the semantic interpretation of statistically significant patterns. We have also discovered that converting the association rules to Jena inference rules bridges the gap between data mining and the semantic web. As the Jena engine can operate on ontologies, it can infer semantically new knowledge. Since the class User in User Profile Ontology consists of interest factors such as race type, location interest, event price, and reward that correspond to the event properties of the Running Event and Race Type class defined in Running Event Ontology, Jena rules can automatically tag a race as a match for a specific user, as demonstrated in Table 8. Furthermore, Jena’s built-in RDFS reasoner automatically understands that any rules applying to the class also apply to a sub-class such as class Race Type, to sub-class Marathon. The Jana inference engine also facilitates real-time personalisation. As the engine is integrated into the application-logic layer, rules are triggered instantly whenever the user adds or updates their profile and preferences. This allows the recommendation list to refresh without costly re-scanning the entire database. Consistently, the framework is both data-driven (via Apriori algorithm) and context-aware (via Jana). Evaluations with real running competitor scenarios confirm that the recommended events and information are accurate and appropriate. This validates that the proposed framework effectively recommends running events aligning with sports tourists’ interests.

3.6.3. Methodological Limitations and Robustness Analysis

However, our proposed framework has limitations. Firstly, the COVID-19 outspread situation caused a considerable decrease in the number of running events between 2019 and 2021. This resulted in little available data and information regarding running events and competitors in between those years to be collected and processed in the research experiment. Secondly, the prototype evaluation of this research was conducted based on running competitor scenarios. It needs to be evaluated by experts and target running competitors to make the recommendation rules more accurate.

Although a dataset significantly impacted by the COVID-19 event reduction, the resulting association rules remain strong, consistent, and predictive patterns. This is because they were generated across factor attributes rather than specific event IDs under strict thresholds (min supp. = 0.2 and a min conf. = 0.8). To ensure the reliability of these findings despite the small sample size, a sensitivity analysis was conducted. We evaluated the stability of the extracted rules by incrementally and decrementally varying the parameters. The results demonstrated remarkable stability, as an increase in the minimum confidence to 0.85 resulted in zero reduction in the number of generated rules (100% retention). This indicates that the condition probability of these underlying associations inherently exceeds 85%. Furthermore, tightening the minimum support to 0.25 retained approximately 73.4% of the baseline rules. This confirms that these behavioural patterns are pervasive across the cohort rather than marginal outliers. Conversely, relaxing the constraints to a minimum support of 0.15 and confidence of 0.75 resulted in only a nominal 7.6% increase in total rules. This high degree of stability confirms that the extracted patterns capture genuine behavioral dependencies rather than random artifacts of threshold manipulation.

However, in the case of a future sustained reduction in marathon events, this data sparsity may reduce the diversity and coverage of niche rules. In a sparse environment, the reliance on a high minimum support threshold (0.2) creates a frequency bias. Rare but significant occurrences, such as charity-type marathons, statistically fail to meet the required frequency. This directly impacts the recall of niche rules (e.g., for R5), where the model essentially overfits to the most frequent patterns. Although these frequent patterns offer high confidence, they often suffer from low informational Lift, providing redundant information rather than novel insights. This can be addressed by potentially reducing the minimum support threshold in conjunction with the use of metrics, including Lift and Conviction, to evaluate the highlight rules that contain the stronger relationships, prioritising statistical significance over simple frequency requirements.

Lastly, in terms of the system scalability and computational implications, the proposed framework is primarily determined by the computational requirements of two distinct stages: offline rule extraction and online semantic reasoning. Since the performance of the Apriori algorithm possesses a theoretical worst-case time complexity of $O\left(2^d\right)$ as discussed in [28,52], where d denotes the number of distinct items or attributes in the dataset, increasing the number of users or events in the future can become computationally expensive. However, this process is executed as an offline batch operation, which does not affect the real-time latency of the recommendation delivery. In contrast, the online stage relies on the Jena inference engine to provide personalised recommendations. Preliminary observations confirm that, for a standard user profile, reasoning times remain within acceptable thresholds for the interactive real-time applications. However, further empirical benchmarking with high-concurrency loads remains a focus for future optimisation.

4. Conclusions and Future Work

This research introduces a novel, ontology-driven framework for context-aware sport tourism recommendations tailored specifically to the needs of running tourists. The framework incorporates a Running Event Ontology and a User Profile Ontology, which serve as its foundational knowledge base. The implemented ontologies structure the relationship between running events and running competitors, consequently reducing data redundancy. The integration of an RBO approach enhances the developed ontologies by incorporating rule-based reasoning to infer new information and make informed decisions. The application of K-modes clustering effectively reduces the complexity of unclassified tourist data by grouping running competitors based on their event participation factors. Furthermore, the Apriori algorithm enables the discovery of recommendation rules from the hidden, meaningful relationships among these factors. The permutation validation confirms the discovered patterns are statistically significant and do not arise from random chance. By combining association rules with Jena rules, our developed prototype bridges the gap between data-driven patterns and semantic understanding. This facilitates adaptive and personalised event recommendations that reflect the changing user interests and trends. The prototype’s evaluation results confirm that our proposed framework efficiently and accurately assists sports tourists by recommending suitable running events that specifically align with their preferences and needs.

For future work, with the extensibility and scalability offered by the RBO and association rules implemented in our framework, we plan to create more comprehensive recommendation rules that cover a broader range of users. This will involve gathering additional data from running events and competitors. Furthermore, we intend to enhance our recommender framework by integrating other contextual information, such as restaurant recommendations based on runners’ interests. Finally, we will evaluate the Quality of Service (QoS) of web services provided by the prototype, especially targeting optimising response times and maximising throughput. As the recommendation engine requires rule extraction and inference, and instance manipulation within the OWL/RDF file, the evaluation of system and computational performance in terms of efficiency and scalability remains a subject for future research.

5. Deployment and Availability

The proposed framework and prototype system with all relevant documents are available at [42].