mirror of
https://github.com/13hannes11/bachelor_thesis.git
synced 2024-09-04 01:11:00 +02:00
add labels to all chapters, sections, tables and figures
This commit is contained in:
@@ -1,6 +1,8 @@
|
||||
\chapter{Introduction}
|
||||
\label{ch:Introduction}
|
||||
|
||||
\section{Research Gap}
|
||||
\label{sec:Introduction:ResearchGap}
|
||||
|
||||
There does not exists much research on recommendation for group configuration, however it is comprised of two different areas of research, recommenders for groups and recommenders for configuration.
|
||||
The existing literature on recommenders for groups is extensive with many different approaches and domains \cite{delicResearchMethodsGroup2016, chenInterfaceInteractionDesign2011, atasItemRecommendationUsing2017, jamesonRecommendationGroups2007, chenEmpatheticonsDesigningEmotion2014, liuCGSPAComprehensiveGroup2019}. \citeauthor{felfernigGroupRecommenderSystems2018} give an overview about basic approaches \cite{felfernigGroupRecommenderSystems2018}.
|
||||
@@ -10,6 +12,8 @@ Group configuration is a more specialized sub field of configuration therefore l
|
||||
%Commonly for content-based recommenders categories based on content are created and a separate user or group profile is generated based on the preferences of whole items. For configuration recommenders however this would create additional modelling or content grouping workload, therefore in this thesis it is proposed to use attributes of a configuration as distinguishing categories.
|
||||
|
||||
\section{Problem}
|
||||
\label{sec:Introduction:Problem}
|
||||
|
||||
A group of people with different personal preferences wants to find a solution to a problem with high variability. Making decisions in the group comes with problems as a lack of communicating leads to worse decision outcomes \cite{atasItemRecommendationUsing2017}. Group dynamics and biases can lead to suboptimal decisions \cite{kerrBiasJudgmentComparing1996}.
|
||||
|
||||
Examples of that are:
|
||||
@@ -22,6 +26,7 @@ Examples of that are:
|
||||
\end{itemize}
|
||||
|
||||
\section{Solution Objectives}
|
||||
\label{sec:Introduction:Solution Objectives}
|
||||
|
||||
\begin{itemize}
|
||||
\item A system should give recommendation for the group using a scoring function that takes into account preferences of group members, the current state of group members.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
\chapter{Foundations}
|
||||
\label{ch:Foundations}
|
||||
|
||||
\section{Definitions}
|
||||
\label{sec:Foundations:Definitions}
|
||||
|
||||
Set of \emph{variables}:
|
||||
\begin{equation}
|
||||
@@ -103,6 +105,7 @@ An example group configuration scoring function is $score_{group}$ with
|
||||
\end{mdframed}
|
||||
|
||||
\section{Recommender Systems}
|
||||
\label{sec:Foundations:RecommenderSystems}
|
||||
|
||||
\subsection{Advantages over Collaborative Filtering}
|
||||
\begin{itemize}
|
||||
@@ -170,7 +173,7 @@ An example group configuration scoring function is $score_{group}$ with
|
||||
\end{itemize} \\
|
||||
\end{tabularx}
|
||||
\caption{A description of the advantages and disadvantages of common recommendation techniques}
|
||||
\label{tab:RecommenderComparison}
|
||||
\label{tab:Foundations:RecommenderComparison}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
|
||||
@@ -1,13 +1,16 @@
|
||||
\chapter{Concept}
|
||||
\label{ch:Concept}
|
||||
|
||||
\section{User Interaction with the System}
|
||||
The system has one main way to be used as defined in \autoref{tab:MainUseCase}.
|
||||
\label{sec:Concept:UserSystemInteraction}
|
||||
|
||||
The system has one main way to be used as defined in \autoref{tab:Concept:MainUseCase}.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=1\textwidth]{./figures/bpmn_configuration_process_with_continious_recommendation.pdf}
|
||||
\caption{A bpmn diagram of the configuration process.}
|
||||
\label{fig:ConfigurationProcess}
|
||||
\label{fig:Concept:ConfigurationProcess}
|
||||
\end{figure}
|
||||
|
||||
\begin{table}
|
||||
@@ -36,19 +39,21 @@ The system has one main way to be used as defined in \autoref{tab:MainUseCase}.
|
||||
\hline
|
||||
\end{tabularx}
|
||||
\caption{A description of the main way users will interact with the system}
|
||||
\label{tab:MainUseCase}
|
||||
\label{tab:Concept:MainUseCase}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
\FloatBarrier
|
||||
|
||||
\section{Solution Objectives}
|
||||
\label{sec:Concept:SolutionObjectives}
|
||||
|
||||
Given an unfinished configuration and preferences of all group members rate a finished configuration on how well "similar" it reflects the configuration and preferences.
|
||||
|
||||
Use this to choose the best finished configuration out of a list to recommend.
|
||||
|
||||
\subsection{Generating a Recommendation}
|
||||
\label{sec:Concept:GeneratingRecommendation}
|
||||
|
||||
Hereby the idea is there is a database of complete configurations (possibly historic from other groups or automatically generated or both).
|
||||
Now the recommendation procedure looks as follows:
|
||||
@@ -61,6 +66,7 @@ Now the recommendation procedure looks as follows:
|
||||
|
||||
|
||||
\section{Benefits}
|
||||
\label{sec:Concept:Benefits}
|
||||
|
||||
The benefits of this approach are, that the need for a group to communicate is reduced. Each user gives their own preferences and the group will get a recommendation based on that. This allows to reduce problems with communication of preferences and eliminates misunderstandings.
|
||||
|
||||
|
||||
@@ -1 +1,2 @@
|
||||
\chapter{Design and Implementation}
|
||||
\chapter{Design and Implementation}
|
||||
\label{ch:DesignImplementation}
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
\chapter{Evaluation}
|
||||
\label{ch:Evaluation}
|
||||
|
||||
|
||||
\section{Evaluation of Case Study}
|
||||
\label{sec:Evaluation:CaseStudy}
|
||||
|
||||
For one example e.g. forest example generate all possible valid configurations.
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
\chapter{Further Work}
|
||||
\label{ch:FurtherWork}
|
||||
|
||||
\section{Possible Extensions or Further Research}
|
||||
\label{sec:FurtherWork:PossibleExtensions}
|
||||
|
||||
\begin{itemize}
|
||||
\item How to optimise such that no need to search through all stored finished configurations is necessary? (e.g. improve runtime from $\mathcal{O}(n)$ to $\mathcal{O}(log\ n)$)
|
||||
|
||||
Reference in New Issue
Block a user