% !TeX encoding = UTF-8
% !TeX spellcheck = en_US

% Document Version: v12

%*******************************************************************************
%* Work Configuration
%*******************************************************************************
\title{An Ontology of Student Consulting Organizations}
\author{Felix Förtsch}
\documentclass[a4paper, DIV=13, BCOR=0cm]{scrbook}

%*******************************************************************************
%* Packages
%*******************************************************************************
\usepackage[english]{babel}
\usepackage[urldate=iso]{biblatex}
\usepackage{xcolor} % Für Farben im Text
\usepackage{xstring} % String-Manipulation; wird von anderen Paketen oft verwendet
\usepackage{fontspec} % Einstellungen für Schriftarten (zB lokales Laden)
\usepackage{csquotes} % Verwaltet Anführungsstriche
\usepackage{hyperref} % Hyperlink-Helfer
\usepackage[defblank]{paralist} % Erlaubt verschiedene neue Listen-Umgebungen (zB inparaenum), defblank für Listenumgebung, die gesetzt wird wie regulärer Text
\usepackage{mdframed} % Erlaubt das einfügen von Kästen (zB Einrahmen von Anmerkungen)
\usepackage{lscape} % Querformat-Umgebung
\usepackage[toc, section=section, numberedsection=autolabel]{glossaries} % Glossar
\usepackage[titletoc]{appendix}
\usepackage{progressbar}
\usepackage{tikz}

%*******************************************************************************
%* Configuration
%*******************************************************************************
% Language
\selectlanguage{english}

% Bibliography
\bibliography{main}
\KOMAoptions{bibliography=numbered}
\KOMAoptions{bibliography=leveldown}

% Table of Contents
%\setcounter{tocdepth}{\paragraphtocdepth}

% SubSubsection numbering
\setcounter{secnumdepth}{5}

% Layout Settings
\KOMAoptions{draft=false}
\KOMAoptions{twoside=false}
\KOMAoptions{titlepage=true}
%\KOMAoptions{headings=small}
\KOMAoptions{parskip=half} % Deaktiviert den den Absatzeinzug

% Header and Footer
\pagestyle{headings}
\KOMAoptions{headsepline=true} % Aktiviert eine Trennlinie zwischen Header und Dokument
%\KOMAoptions{footnotes=multiple}

% Style
%\setmainfont[
%	Path=Fonts/,
%	Extension=.ttf,
%	UprightFont=*,
%	BoldFont=*-Bold,
%	ItalicFont=*-Italic,
%	BoldItalicFont=*-BoldItalic
%]{DejaVuSerif}
%\setmonofont[
%	Path=Fonts/,
%	Extension=.otf,
%	UprightFont=*-Regular,
%	BoldFont=*-Bold,
%]{FiraCode}

%*******************************************************************************
%* Macros
%*******************************************************************************
\newcommand{\eg}{e.\,g.\ }
\newcommand{\Eg}{E.\,g.\ }
\newcommand{\aka}{a.\,k.\,a.\ }
\newcommand{\class}[1]{\texttt{\textbf{#1}}}
\newcommand{\relation}[1]{\texttt{#1}}
\newcommand{\prop}[1]{\texttt{#1}}
\newcommand{\pn}[1]{\textit{\textbf{#1}}}
\newcommand{\foottt}[1]{\footnote{\texttt{#1}}}
\newcommand{\link}[2]{\href{#1}{$\hookrightarrow$#2}}

%*******************************************************************************
%* Glossar
%*******************************************************************************
\glsdisablehyper % Disables hyperlinks for the glossary
\makenoidxglossaries

% Acronyms
\newacronym{sco}{SCO}{Student Consulting Organization}
\newacronym{je}{JE}{Junior Enterprise}
\newacronym{bdsu}{BDSU}{\link{https://bdsu.de}{Bundesverband Deutscher Studentischer Unternehmensberatungen}}
\newacronym{jcn}{JCNetwork}{\link{https://jcnetwork.de}{Junior Consultant Network}}
\newacronym{hc}{HC}{\link{https://hanseaticconsulting.de}{Hanseatic Consulting}}
\newacronym{ci}{CI}{\link{https://campusinform.de}{Campus Inform}}
\newacronym{kiss}{KISS}{Keep It Stupid Simple}
\newacronym{aktg}{AktG}{Aktiengesetz}
\newacronym{gmbhg}{GmbHG}{Gesetz betreffend die Gesellschaften mit beschränkter Haftung}
\newacronym{foaf}{FOAF}{Friend of a Friend}
\newacronym{dcmi}{DCMI}{Dublin Core Metadata Initiative}
\newacronym{dcmt}{DCMT}{Dublin Core Metadata Terms}
\newacronym{bfo}{BFO}{Basic Formal Ontology}
\newacronym{gfo}{GFO}{General Formal Ontology}
\newacronym{fibo}{FIBO}{Financial Industry Business Ontology}
\newacronym{gist}{GIST}{GIST}
\newacronym{schema}{Schema.org}{Schema.org Ontology}
\newacronym{doap}{DOAP}{Description of a Project}
\newacronym{bpmn}{BPMN}{Business Process Modeling and Notation}
\newacronym{epc}{EPC}{Event-Driven Process Chain}
\newacronym{uml}{UML}{Unified Modeling Language}
\newacronym{psl}{PSL}{Process Specification Language}
\newacronym{nist}{NIST}{National Institute of Standards and Technology}
\newacronym{opm}{OPM}{Object Process Methodology}
\newacronym{hrp}{HRP}{Human Resource Process}
\newacronym{pp}{PP}{Project Process}
\newacronym{oc}{OC}{Organizational Context}
\newacronym{pc}{PC}{Project Context}
\newacronym{co}{CO}{Coporate Officer}
\newacronym{ceo}{CEO}{Chief Executive Officer}
\newacronym{cfo}{CFO}{Chief Financial Officer}
\newacronym{cto}{CTO}{Chief Technical Officer}
\newacronym{clo}{CLO}{Chief Legal Officer}
\newacronym{coo}{COO}{Chief Operating Officer}
\newacronym{iso}{ISO}{International Organization for Standardization}
\newacronym{pm}{PM}{Project Management}
\newacronym{owl}{OWL}{Web Ontology Language}
\newacronym{w3c}{W3C}{World Wide Web Consortium}
\newacronym{rdf}{RDF}{Resource Description Framework}
\newacronym{rdfs}{RDFS}{Resource Description Framework Schema}
\newacronym{skos}{SKOS}{Simple Knowledge Organization System}


%*******************************************************************************
%* Dokumentenanfang
%*******************************************************************************
\begin{document}

\titlehead{Overall Progress: \progressbar[filledcolor=yellow]{0.6}}
\subject{Bachelor's Thesis}
\title{Student Consulting Organizations}
\subtitle{A Domain Ontology}
\author{Felix Förtsch \\ 3708438}
\date{01.04.2020}
\publishers{Leipzig University}
\maketitle

\frontmatter
\chapter*{Abstract \progressbar[filledcolor=green]{1}}
	This work develops a domain ontology for \glspl{sco}. The model declares the domain knowledge and defines its vocabulary. It contains the information necessary to establish or run such an organization in a university context. Additionally it allows for optimization in existing organizations and contributes to cooperation between \glspl{sco} by organizing the existing knowledge. It maximizes the use of vocabularies, relations, and classes from established ontologies like \gls{foaf}, \gls{fibo}, \gls{gfo}, and \gls{gist} to link the domain knowledge into a bigger context. The main resource of the developed ontology are \glspl{sco} from Germany, but the concepts can be transferred and made applicable in a wider area.

\chapter*{Formatting}
\begin{compactitem}
	\item Hyperlinks are embedded and clickable in the PDF. They are marked with an arrow and a light blue border: \link{https://hyperlink.com}{Hyperlink}
	\item Everything related to the ontology implementation, such as references to classes or relations, is written as \texttt{typewriter text}.
	\item Relations are written in camelCase: \texttt{subclassOf}
	\item Classes are bold, capitalized, and use Snake\_Case: \texttt{\textbf{Awesome\_Class}}
	\item Name spaces may be added to a class for clarification; they are separated by a colon: \class{namespace:Class}
\end{compactitem}

% To raise awareness for unfairness in society, we use the female form of words where it is possible.

% TODO: Decide on labeling system \url{https://en.wikipedia.org/wiki/Simple_Knowledge_Organization_System}

\chapter*{Leseanleitung}
\newpage

\tableofcontents
\newpage

\mainmatter
\chapter{Introduction \progressbar[filledcolor=yellow]{0.6}}
\section{Motivation \progressbar[filledcolor=green]{0.8}}
\gls{sco}\footnote{Also known as \link{https://en.wikipedia.org/wiki/Junior_enterprise}{Junior Enterprises} in some parts of the world.} are student-run consulting businesses that focus on teaching their members essentials business and life skills exceeding the theoretical knowledge from university. They are very similar to small to medium consulting businesses, but are run and organized---most of the time exclusively---by students. And even though the concept is not universally know, these kind of organizations exists worldwide and have a history dating back to at least 1967\footnote{The founding of \link{https://www.en.junioressec.com/}{Junior ESSEC} in France.}. Germany has two different umbrella organizations for \glspl{sco} with more than 60 member organizations.\footnote{\gls{bdsu}, \gls{jcn}}

But as far as we know, there hasn't yet been any effort to collect and compose the existing domain knowledge of German \glspl{sco} in a publicly available and usable form. We consider this an important task, since it is a contribution to prevent knowledge loss that is inherent in the dynamics of these organizations: the majority of the staff are students and thus their consulting career is inherently linked to their university career:

\begin{enumerate}
	\item The career is time-bound to the duration of the education. A bachelor's degree in Germany averages 7,5-7,6 semesters and a master's degree 4,2-4,5 semesters, which adds up to a total of 11,7-12,1 semesters or ca. six years. \cite{stabu2019a} This frames the available time for the transfer of the domain knowledge.\footnote{There sometimes are also PhD students, but they can be considered outliers and are atypical.}
	\item The career is in parallel to the curriculum. From our experience, freshmen that decide to join student organizations typically do so at the beginning of their second or third semester, after they got acclimated with the workload of their university classes. Since students usually participate in parallel to their education---and the focus is typically on the education---, they have to manage their time accordingly, which reduce time spent with the \gls{sco}. Furthermore, students may have other (\eg personal) interests that compete with the same time budget.
\end{enumerate}

The reasons above reduce the available time for knowledge transfer and persistence and make these problems harder. Many \glspl{sco} have worked on and developed solutions to help with this problem. Some of them are informal, some formal in nature. For example: One particular organization we worked with, \gls{hc}, used process methodology to document a lot of their knowledge. Another we worked with, \gls{ci}, was focusing on lectures and training sessions.

However, the majority of available domain documents are highly individualized and miss the necessary level of abstraction to make them directly applicable to other \glspl{sco}. But even though every \gls{sco} is organized slightly differently than the next, uses different vocabulary and each has their individual culture, they all share the idea of teaching consulting and project work to their members. Since they aim for the same goal, they are very similar at their core.

Therefore we try to contribute a more general model in the form of an ontology that tries to combine the domain knowledge, vocabulary, and common concepts.

\section{Goal and Scope of the Work \progressbar[filledcolor=green]{1}}
\label{goal}
\paragraph{Goal}
The goal of this work is the description of one abstract \gls{sco}. It extracts the available implicit expert knowledge, links it with related work, and transforms it into explicit  knowledge by using an ontology as its vehicle. It defines common classes and relations required to describe such an organization using domain vocabulary. Additionally it provides terminology explanations, background knowledge, and links into other ontologies where it is sensible.

\paragraph{Deliverables \progressbar[filledcolor=green]{1}}
The output of this work are two documents:
\begin{enumerate}
	\item This thesis as a documentation and explanation of the ontology development process including but not limited to: methodology, background information, decisions in regards to the ontology, etc.
	\item The ontology document as a representation of the domain knowledge.
\end{enumerate}

The ontology is publicly hosted and is freely available to any interested parties, such as the umbrella organizations, \glspl{sco}, or students.
%TODO: Public host

\paragraph{Out of Scope \progressbar[filledcolor=red]{0.1}}
\begin{compactenum}
	\item This work is not a thesaurus and not a documentation about a specific Student Consulting Organization.
	\item No diagram for individual orgs
	\item The ontology will not include the individual project process, since projects differ vastly between each other and more general ontologies and frameworks for projects already exists.
	\item No model for projects
\end{compactenum}

\section{Use Cases and Outlook \progressbar[filledcolor=yellow]{0.5}}
The main use case of this work is supporting \gls{sco} idea by the documenting the domain knowledge and helping others to better understand it. We are trying to design the ontology in a way to enable its use for everyone: From the layperson to the expert. It should be possible to support the founding process of a new \gls{sco}, as well as optimize an existing \gls{sco} by comparing it to the model.

Furthermore, we hope to aid the advance of the \gls{sco} idea, by creating a computer-readable ontology that can enable the creation of software projects.

\chapter{Preliminaries \progressbar[filledcolor=yellow]{0.5}}
Ontologies have many applications in various fields. They are used in artificial intelligence research, database design and integration, semantic web, and many more. \cite[p.\,1]{Gomez-Perez:2004aa} One of these applications is knowledge representation.

\begin{quote}
	\enquote{\textbf{Knowledge Representation} is the field of Artificial Intelligence that focuses on the design of formalisms that are both epistemologically and computationally adequate for expressing knowledge about a particular domain.} \cite[p.\,XV, Preface]{baader2017introduction}
\end{quote}

This work is concerned with the knowledge representation of one particular domain: \glspl{sco}. The following section describes how we approach the development of this particular ontology, define the necessary vocabulary and relations between the terms, and structurally explore the domain.

\section{Methodology for the Development of the Ontology \progressbar[filledcolor=green]{0.95}}
The primary goal of this work (see section \ref{goal}) is the creation of a particular domain ontology. Our language of choice for this task is \gls{owl}. It is an ontology language developed by the consensus-driven and well respected \gls{w3c}. \cite[p.\,206]{baader2017introduction} It is widely used and offers very good tooling in the ontology editor \link{https://protege.stanford.edu}{\pn{Protégé}}. It is built and maintained by ontology researchers of \pn{Stanford University}. \cite{musen2015protege} Furthermore the research group provides a ontology development methodology \cite{guide-to-ontology}, that we can build upon. It involves the following steps:
\begin{compactenum}[(1)]
	\item Determine the domain and scope of the ontology,
	\item consider reusing existing ontologies,
	\item enumerate important terms in the ontology,
	\item define the classes and the class hierarchy,
	\item define the properties of classes-slots,
	\item define the facets of the slots, and
	\item create instances.
\end{compactenum}

It is important to note, that even though these steps look like they should be performed sequentially, this is not the case. Instead, the ontology starts out as a draft and is refined during development \cite[Section 3, Introduction]{guide-to-ontology}, following the iterative approach, that is common for ontology development. \cite[p.\,158, section 1.5.1]{stuckenschmidt2010ontologien} This quickly becomes apparent during the process of answering the suggested \pn{Competency Questions} to (1) determine the domain and scope of the ontology \cite[Section 3, Step 1]{guide-to-ontology} and taking into account (2) existing ontologies. And this also is true for steps (3) to (6). Therefore the steps are grouped together to make the overall structure of this work easier to follow.

The phases of the methodology are discussed in more detail in the following two sections and group the proposed steps as follows:

\begin{compactenum}
	\item Steps 1 and 2 are performed during the \pn{Research Phase}.
	\item Steps 3 to 6 during the \pn{Analysis and Synthesis Phase}.
\end{compactenum}

The last step, (7) the creation of instances, is omitted in this work. It is only really relevant if the ontology is used to describe one specific \gls{sco}. \cite{CN} However, this ontology is operating on a higher level of abstraction, trying to describe a more general case.

\subsection{Research Phase}
To our understanding, the main goal of the first part of the methodology is the creation of a foundation for the ontology: It needs to have a clearly defined scope. Additionally the recommended reuse of other ontologies helps creating a web of linked knowledge and reduces the amount of duplicate work.

To find a starting point for data collection and identify existing ontologies, we take an intuitive first look at \glspl{sco} and their driving factor:

\begin{mdframed}
	\textbf{The Idea of Student Consulting Organizations}\\
	Selecting a career is a very difficult and important choice in a young persons life. University education is closely linked to this choice and entering a specific field often requires a specific degree (\eg to become a lawyer, a student has to pass the bar exam).

	Most universities know this and have set up dedicated offices to offer career advice to their students. They not only help picking a fitting course of studies at the beginning of a university career, but also help the students to aim for a fitting job.

	Doing an internship with a company working in the field the student is interested in, is a widespread recommendation. It allows for a glimpse into the profession as well as gathering work experience.

	\glspl{sco} offer an option to investigate a career in business consulting, as well as learning the associated skills and getting paid in the process. They offer the students a way to learn about concept like project based work---the modus operandi of consulting companies---, \eg project planning and management, as well as structuring and presentation of information.

	Consulting is a very diverse field of work. Since consulting can be applied to any field of business, it can be used as a stepping stone into a career.
\end{mdframed}

Observing this intuitive perspective, we can see, that \glspl{sco} are connected to other knowledge domains in various ways: They are a type of social organization and thus are driven by people and processes. Organizations and in extension their processes have actors with responsibilities. This is a hint that the concept of roles might to be a part of the ontology. \glspl{sco} can be generally considered a form of business and therefore business aspects have to be taken into account. The fact that they do consulting work, creates a connection into the domain of (business) consulting and the domain of projects, since consulting work is project based.

This intuitive approach generates a the starting point for the research:
\begin{compactitem}
	\item Previously developed ontologies in related domains, \eg consulting, project management, educational organizations.
	\item Available domain knowledge, \eg process documentation of \gls{hc} and \gls{ci}.
	\item Personal expert domain knowledge and peer-review by other \gls{sco} members.
\end{compactitem}

Furthermore it implies some more general research topics:
\begin{compactitem}
	\item Implications of other general, upper-level, and top-level ontologies, \eg \gls{gfo}, \gls{bfo}, \gls{gist}.
	\item Theory of description logic and ontologies, \eg modeling of roles and processes.
\end{compactitem}

Defining the scope of the ontology is the formal step that concludes the \textit{Research Phase}. This work accomplishes this by answering the Competency Questions. Since the questions can be considered a part of the ontology, they and their corresponding answers can be found as part of the ontology in section \ref{competency-questions}.

\subsection{Analysis and Synthesis Phase}
\label{analysis}
The majority of this work happens during the Analysis and Synthesis Phase. Its goal is the review, interpretation, and structuring of the collected data; ultimately generating an ontology in the target format \gls{owl}.

Based on the Protégé-methodology, the first two steps of this phase are: (3) the creation of an enumeration of terms that are relevant for the domain. And (4) the translation of the terms into the backbone of every ontology: the class hierarchy. Both are rooted in the results of the previous phase and further supplemented by expert knowledge.

At the core of this thought process is the conversion of available implicit knowledge into explicit knowledge. This is a difficult task, since typically the implicit knowledge is not easily available; it's considered an aspect of knowledge engineering. \cite[p.\,30--31]{moore2011towards} To help with it, we introduce a creative step: We start with a brainstorming to create a domain vocabulary collection in the form of a \textit{word cloud}. This simple first step involves writing down all the terms that might have something to do with the ontology. We then can transition this word cloud to a \textit{word graph}, by using the terms as vertices and implement associations between terms (\eg connected ideas or concepts) using the edges. We try to keep the word graph as simple as possible by focusing on the important connections and use existing vocabulary to prepare the links into other domains that will be done in the later stages of development.
% TODO: formally create word cloud

To progress from the word graph to the more rigorous class hierarchy, we transcribe the vertices into a first-draft/skeleton class hierarchy---using the Protégé editor---, starting with the most influential concepts. These can be identified by the amount of edges connecting them to other concepts; more connections indicate higher influence. Furthermore we can identify and assign trivial sub-classes during that process, by evaluating the quality of the edge connections. Fewer connections might indicate a more direct relationship between two terms. After these steps, the draft hierarchy contains mostly high-level classes and trivial sub-classes (\eg high-level class \textbf{Process} and all the identified processes as trivial sub-classes). It can then be further modified, refined, and polished by adding clarifications, delimitations, definitions, and descriptions to all terms as well as relations within the class hierarchy.

During this development process we can identify the aspects that play the most important role for our domain. We document and discuss the challenges and our approach to solving them in detail in section \ref{domain-aspects}.

The output of the final steps is the first major version of the ontology in the form of an \gls{owl} file, which completes the \textit{Analysis and Synthesis Phase} and also the second deliverable of this work.

\section{Definitions \progressbar[filledcolor=green]{1}}
Depending on the ambiguity and complexity of concepts, natural language can quickly become a limiting factor for precision. Definitions are a tool to avoid confusion that arises from unclear semantics. To ensure a common understanding, this section discusses some key terms and their usage throughout this work.

\subsection{Vocabulary}
\label{vocabulary}
Commonly, the term \textit{vocabulary} is used to describe the collection of all words one specific person knows. But this already implies that one person's vocabulary can be different to someone else's. Furthermore, the word vocabulary itself is also overloaded, as the dictionary definition (see appendix \ref{dictionary}) shows. Depending on context the described collection changes. \cite{mw-dictionary}

In the context of ontologies it is used interchangeably with \textit{alphabet} and \textit{signature}. On an abstract level it simply describes a set of symbols. \cite[p.\,46]{loebe2015ontological} Transferred to this work, it is the collection term for all class (see section \ref{classes}) and object property names (see section \ref{relations}), which are mainly words from the English language in conjunction with the underscore (\enquote{\_}) as delimitation symbol. The word choices draw inspiration or are translated from the \gls{hc} process documentation and our experience with different \glspl{sco}, as well as the business world. Some of these words are not special to the domain: \textbf{Organization}, for example, is not only used in many different related ontologies, but also very common in natural language.

To ensure adequate precision, each entry in the vocabulary has a few guaranteed properties (see section \ref{annotation-properties}).

\subsection{Domain Ontology}
The term \textit{domain} is the easy part of this definition, since it intuitively and simply refers to the knowledge area it describes. \cite[p.\,7]{loebe2015ontological} This is close to the dictionary definition (see section \ref{dictionary}), where every listed sense has a delimiting meaning to it. \cite{mw-dictionary}

However, at the time of writing, an exact definition of the term \textit{ontology} is hard to come by. There is no unified understanding across the sciences. \cite{Hesse_2014} Numerous authors tried defining the term as shown by Loebe \cite[p.\,4-6]{loebe2015ontological} and Gomez et al. \cite[p.\, 6--9]{Gomez-Perez:2004aa}, but to our knowledge there has not yet been a conclusive definition. Since it's not our objective to end this discourse, we will not engage in a detailed analysis. Instead, we construct a \textit{working definition} by illuminating different aspects that are important for this work's goal of representing a knowledge domain.

The influential paper \cite[p.\,9]{schulz2012guideline} \cite[p.\,4]{loebe2015ontological} \textit{\enquote{A Translation Approach to Portable Ontology Specifications}} by Thomas R. Gruber---a paper that has been cited more than 19.000 times according to Google Scholar---contains the following definition:

\begin{quote}
	\enquote{An \textbf{ontology} is an explicit specification of a conceptualization.} \cite[p.\, 1]{gruber1993translation}
\end{quote}

Since it is on the more abstract sides for definitions, it is often used as a first step of narrowing down the intended meaning. Baader builds on it and proposes this slightly refined definition:

\begin{quote}
	\enquote{In computer science, an \textbf{ontology} is a conceptual model specified using some ontology language.} \cite[p.\,205]{baader2017introduction}
\end{quote}

This gives us two anchor points to attach it to our work:
\begin{inparaenum}
	\item Our ontology is a conceptual model of a \gls{sco}. We try to adhere as best as possible to the suggestions from the Good Ontology Guidelines: being formal, using explicit specifications, and being adequate for the domain it represents. \cite[p.\,10]{schulz2012guideline}
	\item Our ontology language is \gls{owl}.
\end{inparaenum}

To works further towards our secondary goal of providing an ontology that is usable for software projects, we extend our requirements to the definition for domain ontologies from Jean: 

\begin{quote}
	\enquote{A \textbf{domain ontology }is a formal and consensual dictionary of categories and properties of entities of a domain and the relationships that hold among them.} \cite[p.\,240]{Jean_2007}
\end{quote}

We try to achieve formality by adhering to \gls{owl} standard and using the \textit{HermiT} reasoner during development. To aim for consensus, we prepare the ontology in way so that it can be peer reviewed in the future.

Similar to the general discussion about ontologies, there is an ongoing debate on which term best represents the elements of an ontology. We are following the Protégé naming convention and are calling the collection of elements \textit{entities}. Furthermore we use the term \textit{Classes} to represent things, \textit{Object Properties} to represent relationships between things, and \textit{Annotation Properties} to describe both more closely with additional comments.

\subsubsection{Classes and Class Hierarchy \progressbar[filledcolor=green]{1}}
\label{classes}
Classes are the most basic building blocks of an ontology. Each class tries to capture and describe an entity of the knowledge domain. The name of the class creates a connection between the entity within the ontology and the thing it tries to describe. It is supplemented by additional information via its annotation properties (see section \ref{annotation-properties}). The classes are aggregated an structured in a meaningful way by the \textit{class hierarchy}.

The class hierarchy is a tree where the children of a node have the built in relation (see section \ref{relations}): \relation{subclassOf}. There typically exists a root element called \class{Thing}, which \underline{all} classes are \relation{subclassOf}. As pointed out before, this work follows the \gls{owl} standard and hence we use \class{owl:Thing} as the root element; it has no properties. The built in relation gives additional meaning to classes in the hierarchy. \relation{subclassOf} implies that a class \relation{isA} type of the class it sub-classes. It is therefore key, to only introduce a sub-class relationship, if it is correct for the representation of the domain.

This has implications for our ontology. For example, it is the reason for the different structuring of \class{Agent} and \class{Process}: The former sub-domain can make use of the sub-class relation, whereas the latter cannot (see section \ref{process-subclass}).

\subsubsection{Properties \progressbar[filledcolor=green]{1}}
The classes and the class hierarchy give an ontology its basic structure; they defines what things exist in the world the ontology describes. The \textit{properties} bring this world to life. A property is a binary relation: It can be used to assert facts about a class, describe it in more detail, and to establish relationships between classes. \cite{w3c-owl-guide} We primarily use two types of properties in our work: \textit{Object Properties} and \textit{Annotation Properties}. To make them more distinguishable we also introduce and use their colloquial references \textit{Relationships}/\textit{Relations} and \textit{Annotations}.

\paragraph{Object Properties \aka Relationships \aka Relations}
\label{relations}
To express relationships within the knowledge area, we use object properties. The meaning of a thing is not only defined by its name and description, but also by the connections it has to other things. For example: A \class{Car} by itself conjures a certain image in the readers mind. Adding the relation \relation{hasBrandName} \class{Mercedes-Benz} changes the definition of the car by stipulating an additional restriction.

There are different ways of structuring object properties. The one end of the spectrum holds generalized relations, like \relation{hasA} or \relation{isPartOf}. This type of relationship can be applied to many different classes, because the semantics lies in the connection between the classes, instead of the relation itself. This type of generalized relation can be applied in different contexts. The \relation{isPartOf} relation, for example, can be used in different ways: A \class{Wheel} \relation{isPartOf} a \class{Car}; but also: A \class{House} \relation{isPartOf} a \class{Neighbourhood}.

On the other end fo the spectrum are highly specific relations that carry a lot of meaning by themselves and thus can not be applied to other contexts easily. For example: A \class{Person} \relation{isMemberOfTheMajorityCounil} \class{Member\_Council}.

As with many aspects of ontology development, it is important to strike the right balance and achieve the correct level of abstraction. In this work, we use a bottom-up approach. We start with specific relations and generalize them, if that is possible.

As already mentioned before, there is one special object property that is built into the class hierarchy: \relation{subclassOf}. It would be possible to It links a child class to its parent and expresses that the child is of the same type as the parent. For example: In our ontology, the class \class{Agent} is sub-classed by \class{Person} and \class{Organization}. This implies that both \class{Person} and \class{Organization} \underline{are} \class{Agents}. Everything a \class{Agent} can do, a \class{Person} or an \class{Organization} can also do.

\paragraph{Annotation Properties \aka Annotations}
\label{annotation-properties}
We use annotation properties to add additional information to entities in our domain. They can be thought of simple key-value pairs that are attached to a specific entity. The \underline{key} might be defined within the scope of the ontology or may be sourced from knowledge organization conventions like \gls{rdfs} or \gls{skos}. If a key belongs to such a schema, it uses the corresponding prefix, separated by a colon \enquote{:} (\eg \prop{rdfs:label}). The \underline{value} holds the additional information about a class.

Each class of our domain has two guaranteed annotation properties:
\begin{inparaenum}
\item A \prop{rdfs:label} to define its name in both English and German and
\item a \prop{rdfs:comment} in English, to describe the class more closely.
\end{inparaenum}
Furthermore we provide one or more \prop{skos:example} where examples help describing the class more clearly.

\section{Related Work and Classification \progressbar[filledcolor=red]{0.1}}
\label{related-work}
As already discussed previously, the \gls{sco} domain touches on various other knowledge areas. Related source material could be found in other ontologies, \gls{pm} models and concepts, organizational theory, process documentation and models, established vocabulary, and so forth. The challenge lies in identifying the most useful information and merge the input from many different sources to construct the ontology.

This is made harder by the vastness of some related fields. \gls{pm}, for example, is a central topic for our domain and it is easy to find many different books, theories, and models about it on the market. It is also an complex, overarching, and very general subject matter. Part of its domain are concepts of complex nature like time, problem analysis, and project structuring. If we were to focus too much on this aspect within our ontology, it would easily dominate it and the ultimate goal of our ontology would be  missed. It is therefore imperative to identify the correct level of abstraction and connect the related work in an adequate manner.

This section discusses the related work and shows how we are applying it to the \gls{sco} ontology.



dcterms\footnote{\texttt{dcterms} is used in the \pn{FOAF} rdf file, \texttt{dct} is used in the \pn{FOAF} documentation.}


To reflect on this fact in the ontology, we try to merge the
\subsection{Top-Level Ontologies}
\begin{compactenum}
	\item What is a TLO (Definition)?
	\item What can we use them for in this work? -> Processes, Roles, Time?
	\item What are popular TLOs and what are their strengths and weaknesses?
	\begin{compactenum}
		\item BFO \cite{smith2015basic} %TODO: add note that BFO axioms are extensive and footnotes don't necessarily fully describe a class -> lookup needed
		\item DOLCE
		\item GIST
		\item BPMN  \cite{2014foisbpmn}
		\item GFO \cite{herre2010general}
	\end{compactenum}
\end{compactenum}

\subsection{Upper-Domain Ontologies}
\begin{compactenum}
	\item What is a UDO (Definition)?
	\item What can we use them for in this work?
	\item What are popular UDOs and what are their strengths and weaknesses?
	\begin{enumerate}
		\item OWL-S
		\item \href{https://en.wikipedia.org/wiki/Suggested_Upper_Merged_Ontology}{SUMO}
		\item \gls{fibo}
		\item \gls{doap} https://github.com/ewilderj/doap
		\item \gls{schema}: not really ideal, but useful for general concepts like Person or Organization
		\item \gls{foaf} is close to schema, link to dublin core: "dct:Agent
		\item Enterprise Ontology \url{http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html}
	\end{enumerate}
\end{compactenum}


Dublin Core's notion of Agent is much like FOAF's; Dublin Core says "A resource that acts or has the power to act.", we say "things that do stuff". As nobody has provided a counter-example of something fitting one definition but not the other, we say here that foaf:Agent stands in an 'equivalent class' relationship to dct:Agent (and vice-versa)." \cite[
External Vocabulary References]{Dan-Brickley2014FOAF-Vocabulary}



\section{Principles and Assumptions \progressbar[filledcolor=red]{0.2}}
\label{general-aspects}

\subsection{Keeping Things Simple}
\label{keeping-things-simple}
Polysemy Paper \cite{arapinis2015plea}
\gls{kiss}

keep it as simple as possible (\eg \textit{contract} and \textit{contract document} can be considered two distinct things, but this distinction is not important for the domain knowledge -- maybe add a relation "has document"?)

Example: A contract is a document that captures a business agreement. The word "contract" can refer to the immaterial agreement between the parties, but it can also refer to the document itself. Depending on the use case of the ontology it might be useful to separate these two things.

However, in this ontology the goal is to keep it a simple as possible, since the potential users of this ontology are not necessarily experts.

\subsection{The Unique Name Assumption}
\cite[p.\,299]{Russell:2010aa}
\subsection{Open World Assumption}
Closed world: if a value is not stated, it's false\cite[p.\,299]{Russell:2010aa} \cite[p.\,388]{moore2015context}

Open world: if a value is not stated, it's unknown \cite[p.\,417]{Russell:2010aa} 

OWL is based on the OWA \cite[p.\,389]{moore2015context}
\subsection{Content Completeness Problem}
The \textit{Content Completeness Problem} states, that an ontology is incapable of containing all the concepts relevant to its users.

Developing an ontology involves thinking about the correct level of abstraction and making choices on what to focus on.

\url{https://en.wikipedia.org/wiki/Content_completeness_problem}
As is true for any domain ontology \cite{CN}, the content completeness problem exists for this ontology as well.

active/passive content completeness

bewusst weggelassen:
\subsubsection{Consulting Topics}
The main goal of consulting companies is in their name: consulting. They are a source of expertise and knowledge and can be employed as an option to solve a difficult problem at hand. The problem space of consulting companies is vast; examples are: Digitization, Human Resources, Knowledge Management, Market Research, Marketing, Coporate Strategy, etc. These topics are obviously part of the consulting domain. However, they are deliberately omitted, since their exploration would exceed the scope of the work.

\subsubsection{IT and Communication Systems}
IT systems are an essential part of modern business and there are companies where these systems are integral to everything (\eg AI companies). However, in the context of a consulting company they are mainly used to support, supplement, and optimize the already existing processes. Hence, a model of an IT system would not contribute in a meaningful way to the ontology.

\subsection{Time}
\label{time}
Implement time abstract -> only needed for processes before/after
no absolute time

\gls{bfo} \gls{gfo} have complex implementations of time that are not needed in this ontology.

\chapter{Ontological Aspects in the SCO Domain \progressbar[filledcolor=yellow]{0.7}}
\label{domain-aspects}
At the center of our domain lies a social structure. It is driven by processes and interactions that involve people. Such social constructs are inherently complex. For example: The same individual can often act in multiple capacities, actors can be part of different groups and these groups can have different degrees of formalization, the contexts of interactions are dynamic and fluid, etc. The challenge lies in modeling the domain in a way that it is adequately represented, but not too complex to use.

In the following section, we discuss three distinct and noteworthy aspects that we encountered during the modeling of our domain:
\begin{inparablank}
	\item The impact of \textit{context} and the relevant contexts in this work,
	\item \textit{social constructs} and how we work with them, and
	\item our model for \textit{processes}.
\end{inparablank}

Please note, that there are other classes and relations present in the ontology---and also describes in section \ref{ontology}---that are relevant to the domain, but \textit{not} discussed in detail in this part of the work (\eg \class{Document}).

\section{Context \progressbar[filledcolor=green]{0.9}}
\label{context}
Context plays an important role in knowledge engineering. Things can take on a different meaning, depending on which context they are presented. Accounting for it poses a challenge for any ontology, because of its inherent complexity and domain specificity \cite[p.\,1]{moore2012intelligent}. It is important to note that context can, but doesn't have to be modeled explicitly. It indirectly influences all entities; however, the degree of influence can change from one to another.

To better understand how context is handled in our work, we start with its definition:
\begin{quote}
	\enquote{\textbf{Context} is any information that can be used to characterize the situation of entities (i.e., whether a person, place, or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves. Context is typically the location, identity, and state of people, groups, and computational and physical objects.} \cite[p.\,106]{dey2001conceptual}
\end{quote}

This means that every entity of an ontology is affected by context. In extension, the same is true for the ontology itself and the user who uses the ontology. Solving the contextual problem is out of scope of this thesis; however, we try to alleviate the challenges that context brings into play.

We focus on two aspects:
\begin{inparaenum}
	\item The description of the domain context and sub-contexts within it.
	\item Contextual ambiguity and how we are trying to mitigate its impact.
\end{inparaenum}

\subsection{Primary Domain Context and Sub-Contexts}
To define the primary context of our domain, we first have to take a look at \textit{what} exactly we are modeling. As stated in the introduction (see section \ref{goal}), the goal of our work is the creation of an abstract \gls{sco}. We consider it a form of \textit{idealized blueprint}, that can later be used to create concrete instances of this type of organization. It is clear that this can happen more than once and that different \glspl{sco} can co-exist and interact with each other, influencing each others contexts. However, we are deliberately \textbf{not} modeling \underline{all} \glspl{sco} in one ontology.

Hence, \underline{one} \gls{sco} is the primary and default context of the ontology and that all the classes have to be interpreted and understood in this particular way. If one were to extend our model to incorporate multiple \glspl{sco}, it would be necessary to develop dedicated links between instances. This primary context is active for all the classes within the scope.

For \gls{sco} the primary goal is the education of its members in the consulting profession. As already pointed out, the central idea is \textit{learning/teaching by doing} by creating project opportunities with clients and enabling the members to work on these projects together. The organization built around this idea is a tool that helps to achieve this goal; the same is true for the projects.

We can identify two different sub-contexts whose interplay describe the inner workings of an \gls{sco}: The project and the organization. Everything that happens within an \gls{sco} can be attributed ot at least one of these contexts.

Projects are a very goal orientated flexible work structures that can be applied in a wide array of situations. There exist a multitude of concepts, models, and books on the topic and there even exist a dedicated profession that specialists in this kind of work: \textit{Project Management}. The project domain itself is vast and therefore it is out of scope of this work to model the project domain completely. However, since projects are undeniably a major part of the \gls{sco} domain, we have to identify the aspects that have an impact on our ontology. 

A project is an organizational construct that exists to reach a common goal, as pointed out by the \gls{iso} definition:

\begin{quote}
	\enquote{A \textbf{project} is unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources} \cite{iso-9000-2015}
\end{quote}

As already pointed out, projects are the tool of choice for educating the \gls{sco} members. The organization can be thought of as the central hub for multiple projects: It is the entity that frames each projects life cycle. It ensures sufficient starting conditions, provides external support during a projects duration, and accompanies its finalization. The content of each individual project does not impact the ontology. Hence, we can look at each project as a black box similar to a function. Our model has to consider the project inputs (\eg personnel) and its outputs (\eg documents), as well as a model for interactions between a running project and the organization.

%TODO: Write how the context is modeled
%\begin{compactenum}
%	\item The typical \gls{sco} requires project members to be formal members of the organization itself.
%	\item A member can be part of a project and part of the organizational structure at the same time.
%\end{compactenum}

\subsection{Contextual Ambiguity}
Ontology engineering relies on natural language to describe concepts. This work uses primarily English words (see section \ref{vocabulary}) for this task. That naturally introduces a form of contextual ambiguity, because people often use words in a flexible manner. \cite[p.\,7, 1.5.2]{uschold1998enterprise}  It's our goal to keep the ontology as simple as possible. It is therefore important to find a way to avoid ambiguity as much as possible.

Let's imagine a domain \class{Dreamworld} that is home to a \class{Person}. At first glance the concept seems to be intuitive. However, when looking more closely and realizing that in the \class{Dreamworld} a \class{Dreamworld:Person} \relation{hasPart} \class{Dreamworld:Wheel}, this concept of a \class{Person} would suddenly appear odd. It would stray away from the common understanding.

This small example shows: Contexts are part of the concept definition--and natural language comes \textit{pre-loaded} with context. In the case of \class{Person}, the injected context is the common understanding of what a person is, implied by the English language. We call a context that is automatically assumed in the absence of a context an \textit{Implied Context}.

It is also possible to specify the context of a class in such a way, that ambiguity is impossible. We call such a context a \textit{Defined Context}. One way to impose a defined context, is to avoid common words all together and use cryptic randomly generated word-letter combinations---\eg TJKY0123---as class or property names. When the name has no meaning, all its meaning comes from its definition and relationships.

However, this approach discards all previous knowledge about a concept. Furthermore, an ontology built this way would be hard to work with for another human being.

Another way is to start with the implied context and add explanations, comments, clarifications, and restrictions to it, to make the meaning as clear as possible; building the required context in the process. This can be furthered by using already existing definitions from pre-definied name spaces and established ontologies (see section \ref{related-work}).

We are using the latter approach and try to avoid additional ambiguity by discussing the relevant contexts explicitly as part of this work, as well as add explanation texts to the ontology. Furthermore we try to lean on common understand of terms as much as possible, by creating links to well-known ontologies like \gls{foaf}.

\section{Social Constructs \progressbar[filledcolor=green]{0.9}}
 This section deals with the model for human beings.
 \eg as a \gls{sco} member or -non-member, as part of a project, as a customer, etc.
 Aggregation of these actors can occur in different degrees of formalization, \eg informal meeting of \gls{sco} members as friends, a project team meeting, an official meeting of the member council, etc. 

Since this is not a domain specific phenomenon, it is sensible to consider how existing and related ontologies (see section \ref{related-work}) represent these cases.

\subsection{General Implementation}
\label{human-beings-in-other-ontologies}
Starting with the general model of human beings, \gls{foaf} is a very common choice when thinking about representing social structures. It is a well established ontology and referenced multiple times as backbone for social concepts. Its implementation and description are relatively basic: The anchor is the top-level class \class{foaf:Agent}\foottt{foaf:Agent rdfs:comment: \enquote{An agent (eg. person, group, software or physical artifact).}}, which is referred to as the class of \enquote{things that do stuff}. It is connected to the name space of the \gls{dcmt} via \relation{equivalentTo} \relation{dcterms:Agent}. It is sub-classed by
%
\class{foaf:Group}%
	\foottt{foaf:Group rdfs:comment: \enquote{A class of agents.}},
%
\class{foaf:Organization}%
	\foottt{foaof:Organization rdfs:comment: \enquote{An organization.}},
%
\class{foaf:Person}%
	\foottt{foaof:Person rdfs:comment: \enquote{A person.}},
%
\class{Person}%
	\footnote{\label{footn:no-desc}Note: The ontology doesn't offer any description.}, and
\class{schema:Person}%
	\footnote{See footnote \ref{footn:no-desc}.}.
\class{Person} and \class{schema:Person} are \relation{equivalentTo} \class{foaf:Person}.%
	\footnote{The link to \gls{schema} was added in the last update in 2014.} \class{foaf:Person} and \class{foaf:Organization} are disjoint. \class{foaf:Group} aggregates any type of \class{foaf:Agent}. \gls{doap} reuses exactly the same classes as \gls{foaf}. It also has the same links to \gls{schema} and \gls{dcmt}.

\gls{schema} implements
\class{schema:Person}%
	\foottt{schema:Person rdfs:comment \enquote{A person (alive, dead, undead, or fictional).}} and
%
\class{schema:Organization}%
	\foottt{schema:Organization rdfs:comment: \enquote{An organization such as a school, NGO, corporation, club, etc.}}.
%
\class{schema:Person} is considered \relation{equivalentTo} \class{foaf:Person}. This establishes a two-way link between \gls{foaf} and \gls{schema}. \class{schema:Organization} is sub-classed to accommodate for specialized forms of organizations that are relevant for the use cases schema was developed for, \eg \class{schema:Airline}, \class{schema:NGO}. A collection class like \class{foaf:Group} does not exists explicitly, but a \class{schema:Person} as well as a \class{schema:Organization} can be a \relation{memberOf} an \class{Organization}.

\gls{fibo} uses very similarly named classes with a more complex description. The root class is called
%
\class{fibo:AutonomousAgent}%
	\foottt{fibo-fnd-aap-agt:AutonomousAgent skos:definition: \enquote{An agent is an autonomous individual that can adapt to and interact with its environment.}}. It is sub-classed by
%
\class{fibo:Person}%
	\foottt{fibo-fnd-aap-ppl:Person skos:definition: \enquote{a person; any member of the species homo sapiens}}, %
%
representing individual humans. Like in \gls{foaf}, this class is disjoint with
%
\class{fibo:Organization}%
	\foottt{fibo-fnd-org-org:Organization skos:definition: \enquote{a unique framework of authority within which a person or persons act, or are designated to act, towards some purpose, such as to meet a need or pursue collective goals on a continuing basis}}.
%
\class{fibo:Group}%
	\foottt{fibo-fnd-org-fm:Group skos:definition: \enquote{a collection of autonomous entities}}
%
exists as a \relation{subclassOf}
%
\class{fibo:Collection}%
	\foottt{fibo-fnd-arr-arr:Collection skos:definition: \enquote{a grouping of some variable number of things (may be zero) that have some shared significance}}
%
and is described as collection of \class{fibo:AutonomousAgent}, which in turn is \relation{subclassOf}
%
\class{fibo:Arrangement}%
	\foottt{fibo-fnd-arr-arr:Arrangement skos:definition: \enquote{an organizing structure for something}}.
%
\gls{gist} offers the three classes
\class{gist:Person}%
	\foottt{gist:Person rdfs:comment: \enquote{NEGATIVE EXAMPLE: fictional characters.}},
%
\class{gist:Group}%
	\foottt{gist:Group rdfs:comment: \enquote{A collection of People. The group may or may not be an Organization. Many organizations consist of groups of people, but that is not a defining characteristic.}}, and
%
\class{gist:Organization}%
	\foottt{gist:Organization rdfs:comment:
		\begin{inparaenum}
			\item \enquote{A generic organization that can be formal or informal, legal or non-legal. It can have members, or not.},
			\item \enquote{EXAMPLES: Legal entities like companies; non-legal entities like clubs, committees, or departments.},
			\item \enquote{NOTE: There are a plethora of different kinds of organizations that differ along many facets, including members, structure, purpose, legal vs. non-legal, etc.}
		\end{inparaenum}
	}
as its implementation of the social structure.
However, the classes are organized very differently in the hierarchy and use the \relation{subclassOf} relation more extensively compared to \eg \gls{foaf}: To fully extract all information about the class \class{gist:Person}, its whole class path has to be taken into account.
A \class{gist:Person} is \relation{subclassOf}
%
\class{gist:LivingThing}%
	\foottt{gist:LivingThing rdfs:comment:
		\begin{inparaenum}
			\item \enquote{EXAMPLES: A cat, a mushroom, a tree.},
			\item \enquote{NEGATIVE EXAMPLES: fictional life forms such as Unicorns or Mickey Mouse.},
			\item \enquote{NOTE: In the open world, you must assume that it might have since died.},
			\item \enquote{Something that is now, or at some point in time was, alive and growing.}
		\end{inparaenum}
	},
which in turn is \relation{subclassOf}
%
\class{gist:PhysicalIdentifiableItem}%
	\foottt{gist:PhysicalIdentifiableItem rdfs:comment:
		\begin{inparaenum}
			\item \enquote{EXAMPLES: a computer, a book.},
			\item \enquote{NEGATIVE EXAMPLE:  A discontinuous thing like a manufacturing line cannot reasonably have an RFID attached to it, even though its parts are not the same kind of thing as the whole.},
			\item \enquote{NOTE:  You could, at least in principle, put an RFID tag on members of this class. Physical things are made of something.  E.g., statues are made of bronze.},
			\item \enquote{NOTE: In practice, this always means that the parts are not the same kind of thing as the whole.}
		\end{inparaenum}
	};
and both parent classes are carrying additional properties.
Similarly \class{gist:Group} is \relation{subclassOf}
%
\class{gist:Collection}%
	\foottt{gist:Group rdfs:comment:
	\begin{inparaenum}
		\item \enquote{Any identifiable grouping of instances.  For instance, a jury is a collection of people.},
		\item \enquote{EXAMPLES: A jury is a group of people,   a financial ledger is a collection of transaction entries; a route is an (ordered) collection of segments.}
	\end{inparaenum}}
with the limitation of every \class{gist:Group} \relation{hasMember some} \class{gist:Person}.

\gls{bfo} and \gls{gfo} don't offer any directly usable implementation for this specific problem, since they operate on a different level of abstraction.

When looking at the related work, we make the following observations:
\begin{enumerate}
	\item The modeling of human beings is concrete and intuitive: It operates on a low level of abstraction. Concepts that are in use by the layperson, \eg \class{Person} and \class{Organization}, are commonly used in reviewed ontologies; except for the top-level ontologies that operate on a much higher level of abstraction and are therefore not concerned with the concreteness of modeling human beings.
	\item The class \class{Agent} represents actors of an action. Sub-classing it gives the model freedom to express what exactly acts: It can be an \class{Agent}, a \class{Person}, a \class{Group}, or an \class{Organization}. This flexibility makes the models powerful. They can describe general (\eg somebody) or other agents (\eg robots) directly via \class{Agent}, but can also be used more specifically via a sub-class (\eg a \class{Person}). Additionally, a group is a collection class that is also \relation{subclassOf} \class{Agent} and hence can become an \class{Agent}---an actor---itself.
\end{enumerate}

As shown above, the classes \class{Agent}, \class{Person}, \class{Organization}, and \class{Group} are common in the class hierarchies of the related ontologies. Therefore this ontology will use these classes. However, the different ontologies also use different ways of defining classes. Ranging from the very direct and simple way of \gls{foaf}, to the very intricate way of \gls{gist}. Since this ontology is trying to be as intuitive to use as possible, the more simple approach from \gls{foaf} is adapted.\footnote{This decision is a direct application of the \gls{kiss} principle (see section \ref{keeping-things-simple}). Having more information in an ontology can obviously be useful for a very detailed model of a domain. However, its size can be kept smaller and the complexity lower by omitting information (\eg certain relations or attributes) that can be inferred from linked ontologies when necessary. For example: \gls{fibo} and \gls{gist} offer attributes for a \class{Person}; \eg in \gls{fibo} a \class{Person} \relation{hasDateOfBirth exactly 1} \class{Date}, in \gls{gist} a \class{Person} is \relation{offspringOf} another \class{Person} and need to have a \relation{name} \class{xsd:string}. These attributes can be extracted on demand, by following the \relation{equivalentTo} relation.}

After deciding on these basic building blocks, they can be extended according to the additional domain specifications. For example, a \class{Person} might need further differentiation based on \gls{sco} membership status, on business rank for internal organization and career progress, or on organizational roles. But there are other concepts that can involve a \class{Person}---\eg \enquote{\textit{being a customer} of the \gls{sco}}---that could just as easily involve an \class{Organization}. This observation points to the requirement of a more general approach for modeling these cases: Roles.

As already shown by \textit{Loebe}, the concepts and ideas about roles have been heavily discussed in the ontology community and literature. \cite[p.\,130~1.2]{loebe2007abstract} The role concept is not trivial, very fundamental, and using it as part of an ontology allows for a flexible and powerful model.
Since there is no clear agreement on a particular role concept, we are adopting the approach from \textit{Loebe} (2007) and its basic role model. It is very general and can be applied in various ways: It can be used in the intuitive way regarding social roles, \eg thinking about a human being playing the role of a patient and another the role of a doctor. But it is also possible to think about numbers and relationship between them in the form of abstract roles. \cite[p.\,131--133]{loebe2007abstract}

The strength of the role concept is its flexibility. A player can play multiple roles at the same time and each role can be associated with a different context. An example for this is the CEO role. It has defined responsibilities and playing the role means a requirement to fulfill certain tasks. With \glspl{sco} typically any formal \class{Member}---in our ontology this means any \class{Member} with rank \class{Junior Consultant} or above---can become CEO by being elected. When elected, the \class{Member} plays two roles in the \gls{oc}. Additionally, the same \class{Member} could work on a project as \class{Project Leader}, a role from the \gls{pc}.

Since \glspl{sco} are a social construct and are defined by the people of the organization, the modeled roles are primarily from the type \textit{social role}. Furthermore, the contexts described in section \ref{context} also have implications for the roles that exists in the domain.

\subsection{Roles in the Organizational Context}

\subsubsection{Membership}
\label{membership}
Within the \gls{oc} (see section \ref{context}), the most basic property is membership: Either being part of the organization and thus being a \class{Member} or not participating and a \class{Non-Member}. \class{Members} of the \gls{sco} can play different roles in the \gls{oc}. \class{Non-Members} don't play roles within the organization, but can play external roles. For example: The role of a \class{Customer}. The distinction is important for this ontology, since the status is typically used in the internal organizational procedures. For example: Someone might be required to be a proper member to be allowed to vote in the Member Assembly, to be part of a project, or to become part of the Executive Board.

It is important to note, that within \glspl{sco} the \class{Member} role can only be played by human beings. For this model this means a restriction to \class{Person}. The members are the defining group that fills all the organizational functions, works on the projects, and participates in the majority of processes. Even though membership does not have to be limited like this in general---there are many examples where organizations are members of other organizations---it is limited in this domain. Since \class{Member} are necessarily \textbf{always} human beings, we introduce the role as \relation{subclassOf} \class{Person}.

The \class{Non-Member} role, however, is not limited to only \class{Person}. In fact, everything and everyone that is not a \class{Member} is by definition a \class{Non-Member}. Therefore it is sufficient to model the class \class{Member} and omit \class{Non-Member}.

\subsubsection{Business Ranks}
\label{ranks}
The second property a \class{Person} can have in the \gls{oc} is the business rank. Examples from the business world are: Associate, Senior Associate, Consultant, Partner, etc. Similar to regular businesses, \glspl{sco} also organize these ranks around their career process: A person receives the lowest available rank at the begin of their career. During the time with the organization a person is awarded higher ranks based on some organizational system (\eg a merit-based system), until the highest rank is reached or the person leaves the organization.

The exact terms for the ranks, their meaning, gradation, and organizational implications are highly specific to the \gls{sco} instance. We therefore introduce a rough and extensible skeleton representation:
\begin{compactenum}
	\item \class{Trainee}: The entry level rank, without a formal membership.
	\item \class{Junior Consultant}: The first rank after someone acquires an official, formal membership.
	\item \class{Consultant}: The rank that implies someone has reached the required amount of knowledge and experience to fulfill all organizational functions.
	\item \class{Senior Consultant}: The ultimate rank of the organization that can be reached after gathering a substantial amount of knowledge, experience, and organizational social status.
\end{compactenum}

\class{Ranks} can only be attained by \class{Members} and therefore both are directly related. Since a \class{Member} can only hold exactly one \class{Rank} and the \class{Rank} further specifies the \class{Member} in the \gls{oc}, we introduce the ranks as \relation{subclassOf} \class{Member}. This is similar to the \gls{schema} approach that sub-classes \class{Organization} to be more specific about the type of organization: We are sub-classing \class{Member} to be more specific about it.

\subsubsection{Corporate Officers}
The complete set of tasks and responsibilities for the organizations day-to-day leadership is associated with the group of people referred to as \glspl{co}. This set is typically divided into sub-sets and each sub-set is associated with a different role, to organize the work loads; each role is played by a different person. For example: An organization may have the roles \gls{ceo}, \gls{coo}, and \gls{cfo} and each is played by a different individual.

The exact set of task differs from \gls{sco} to \gls{sco} and is also dependent on the organizational form, \eg a \gls{sco} using the form of a registered association has different (legal) obligations than a \gls{sco} organized as university group. Completely specifying it is impossible on the level of abstraction this ontology operates on. In the same vein, it is impossible to define which tasks are attributed to which role, since every \gls{sco} organizes differently. Therefore we fall back on an extensible model and introduce the general class \class{Coporoate\_Officer} as \relation{subclassOf} \class{Organizational\_Role}. To play a leadership role, it is required to be a formal \class{Member} of the \gls{sco}. Hence: \class{Coporoate\_Officer} \relation{isPlayedBy} only
(\class{Junior\_Consultant} or \class{Consultant} or \class{Senior\_Consultant}).

There exists some common roles, that arise from the necessities of an \gls{sco}: There is typically a person that is formally responsible for the organization, a person that takes care of the finances, and a person that takes care of legal aspects of the project work. We differentiate between these three branches explicitly and introduce dedicated roles for each: \class{Chief\_Executive\_Officer}, \class{Chief\_Financial\_Officer}, and \class{Chief\_Legal\_Officer}.

It is important to note that these roles can all be played by the $\underline{same}$ \class{Person}. And: That we do not introduce any concrete tasks these roles have to fulfill.

\subsubsection{Alumni, Advisor, and Patron}
In the duality of membership---\class{Member} vs. \class{Non-Member}---exists some roles, where an assignment to either group is not clear cut when projecting on the real world: Alumni, advisors and patrons. All of these roles can be played by \class{Members}, \class{Non-Members} or a \class{Group} of both. The role attribution depends on the internal organization of the particular \gls{sco}. Furthermore each of the roles have their own restrictions.

Alumni are a group of people that have been affiliated with an organization in the past, but are not members of that organization anymore. A good example are university alumni: The group of people that graduated from a specific university. Becoming an alumni typically is an informal and passive process that only requires previous \gls{sco} membership. However, it is also possible to interpret alumna as a more formal role and title, requiring being a \class{Member}. The common denominator in our model is the $\underline{previous}$ membership. Since this is a requirement and \class{Member} is restricted to be played by only \class{Person}, the same holds true for alumna. Furthermore, the previous membership also implies, that an alumna does not hold an internal rank anymore. We introduce \class{Alumna} as \relation{subclassOf} \class{Organizational\_Role}, restrict the player to \class{Person}, and specify a \relation{disjointWith} (\class{Trainee} or \class{Junior\_Consultant} or \class{Consultant} or \class{Senior\_Consultant}).

Advisors are selected (\eg appointed, chosen, elected) to assist the \gls{sco} leadership with a neutral perspective in their decisions. Becoming an advisor is an active, conscious process. Both parties, advisees and advisors, are necessarily restricted to \class{Person}: The leadership of the organization is recruited from the pool of members; and the advisory concept models a direct and personal exchange of assistance. We introduce \class{Advisor} as \relation{subclassOf} \class{Organizational\_Role} that can only be played by \class{Person}.

Patrons are financial and/or ideological supporters of the \gls{sco}: A financial patron directly contributes to the monetary funds of the organization; an ideological patron primarily supports the idea of \gls{sco} and contributes through non-financial means. Both roles can be played by one player simultaneously. Often times ideological patronage also involves a form of financial support and vice versa. For example: The associated university of the \gls{sco} may provide patronage (\eg allowing promotion on the university website and campus) and infrastructure (\eg offices, meeting rooms, etc.). We introduce \class{Patron} as \relation{subclassOf} \class{Organizational\_Role} and further specify \class{Financial\_Patron} and \class{Ideological\_Patron} as \relation{subclassOf} \class{Patron}. Since patronage, especially financial support, require contracts, the role can only be played by a formal entity: It is restricted to \class{Person} and \class{Organization}.

\begin{mdframed}
	\textbf{Note:} The model says nothing about social status and political power that typically come with ranks and roles, such as being a \gls{co} or advisor, within an organization (\eg a person that holds a rank or role for a long time may still have organizational power after stepping down: \link{https://en.wikipedia.org/wiki/Éminence_grise}{Éminence grise}).
\end{mdframed}

\subsection{Roles in the Project Context}
As discussed in section \ref{context}, we look at projects as black boxes. We focus on their inputs and outputs, as well as the support during its life cycle. This perspective influences the role model, since the primary inputs are people playing a certain role in the \gls{pc}. The \textit{roles} of a project are: the team---consisting of team leader and team members---, the controlling entity, and the customer. The roles in the \gls{pc} operate on a higher, more general level of abstraction when compared to the classes in the \gls{oc}, to account for the generality if projects.

\subsubsection{Project Team}
A project team in its most basic form consists of team members that are lead by a team leader. The project team leader is typically a more experienced member of the organization, to ensure the knowledge transfer and successful operation of the project, whereas the team members are recruited from the general member pool.

We model \class{Project\_Team\_Member} and \class{Project\_Team\_Leader} as \relation{subclassOf} \class{Project\_Role}. To indicate that these roles are only played by members of the organization, both are \relation{playedBy only}
\class{Alumna} or \class{Consultant} or \class{Junior\_Consultant} or \class{Senior\_Consultant}. Additionally the \relation{isPlayedBy} relation of the role \class{Project\_Team\_Member} is extended with \relation{or} \class{Trainee}, to account for the fact that trainees in a \gls{sco} can not become the \class{Project\_Team\_Leader}. By using \class{Trainee} our model binds the cut-off point for the leadership role to the formal membership (see section \ref{ranks}).

The \class{Project\_Team} itself is not a role. However, it is a relevant entity of the ontology. It is a collection of certain \class{Members} of the \gls{sco}, that each either play the role of a team member or a leader. We model it as \relation{subclassOf} \class{Group}. This also gives it the ability to act as an \class{Agent}: It \relation{participatesIn} a \class{Project} and \relation{signsContract} the \class{Project\_Contract}.

\subsubsection{Project Controlling}
In addition to the team, the \gls{sco} typically provides a controlling entity for the project. It observes and measures the progress of the project, gives feedback on the project work, and helps the team in various capacity where necessary. The role of the controlling entity is usually played by someone or some group---both are common in the domain---, that has gathered experience with projects in general and has specific knowledge that is useful in the project it supports. Additionally, using an experienced controlling entity helps the learning process of the team.

We model \class{Project\_Controlling} as \relation{subclassOf} \class{Project\_Role}. We model the players as a group of experienced members; if an organization only uses a single member to play the controlling entity, our models considers it a group of one ($n = 1$). We encode the required experience into the ranks (see section \ref{ranks}), cutting out \class{Trainee} and \class{Junior\_Consultant}. This means the role \relation{isPlayedBy only} (\class{Group} and \relation{hasMember} some (\class{Alumna} or \class{Consultant} or \class{Senior\_Consultant})).

\subsubsection{Customer}
The remaining party of a basic project is the \class{Customer}. It represents the actor that wants to reach a goal and sets up a project with the \gls{sco} to reach it. Similar to other aspects in the \gls{pc}, we use a minimal approach to the role to accommodate for the required flexibility. We model it as \relation{subclassOf} \class{Project\_Role} and allow it to be played by any \class{Agent}. To work on a \class{Project}, the \class{Customer} \relation{signsContract} the corresponding \class{Project\_Contract}.

\section{Processes \progressbar[filledcolor=yellow]{0.4}}
\label{processes}
Processes are a helpful concept when describing organizations: They are created to achieve a goal and its processes are the steps needed to reach that goal. \cite[p.\,5, Definition 1.1]{Weske:2019aa} In theory, every organization can be decomposed to a sequence of single activities, which, when executed correctly and in the correct order, terminate in reaching the goal of the organization.

Since processes are a commonly used concept in the business world, it is not surprising, that many different methods and frameworks for modeling them have been developed. They often revolve around visual representations of all workflows that make up an organization. Combining process models with goals and measurements makes them a powerful tool for optimization and quality control. For example, ISO 9001 is an industry standard that uses a process approach as the foundation of measuring quality. \cite{iso-process-approach} Because process documentation contains a lot of data about organizations, it is also a valuable source for ontology development.

Widely known representations and methods include: Flowcharts, \gls{bpmn}, \gls{epc}, \gls{uml} Activity Diagrams, and \gls{opm}\footnote{Standardized as ISO~19450.}. There are also contributions rooted in ontology research, such as the \gls{bpmn} ontology (an \gls{owl} ontology for the \gls{bpmn} notation) \cite{2014foisbpmn}, the \gls{psl}\footnote{Developed by the \gls{nist} and standardized as ISO~18629.}, and processes concepts as part of \gls{gfo} or \gls{bfo}.

Our intent is the representation of the required \textit{core} processes of an \gls{sco} in such a way, that it makes it clear to the ontology user \underline{which} process have to be implemented, but leaves enough creative freedom in regards to \underline{how} to implement them.

\subsection{Implementation in Related Ontologies}
% TODO: Was verfolgt die jeweilige Implementierung für ein Ziel? Irgendwie einen Schluss aus der betrachtung ziehen
When compared to the rather practical and direct implementation of social structures discussed in section \ref{human-beings-in-other-ontologies}, processes are a more abstract concept. The impact of abstraction levels clearly shows when analyzing related ontologies. For example: While \gls{foaf} is a good source when discussing its niche---the modeling of connection between human beings---it does not require an implementation of a process concept. The closest link from \gls{foaf} to a process representation is the  class \class{foaf:Project}\foottt{foaf:Project rdfs:comment: \enquote{A project (a collective endeavour of some kind).}}, which can be viewed as a procedural concept. However, it doesn't offer any additional reusable detail.

A similar observation can be made for \gls{schema}. Its primary purpose is adding semantic meaning to the internet: \enquote{Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.} \cite{schema-mission} Hence, it is not surprising, that it doesn't implement a detailed process representation. The other time-related class that could be connected to processes, \class{schema:Event}, is geared towards content description (\eg \class{schema:Business\_Event}, \class{schema:Sports\_Event}) and website interaction (\eg \class{schema:User\_Likes} \relation{subclassOf} \class{schema:User\_Interaction}) instead.

On the other hand, the two top-level ontologies, \gls{bfo} and \gls{gfo}, implement process concepts on such a high level of abstraction, that they are not directly applicable for our domain process model:
%
\gls{bfo} uses the class %
	\class{bfo:Occurent}\foottt{bfo:Occurent elucidation: \enquote{An occurrent is an entity that unfolds itself in time or it is the instantaneous boundary of such an entity (for example a beginning or an ending) or it is a temporal or spatiotemporal region which such an entity occupies\_temporal\_region or occupies\_spatiotemporal\_region. (axiom label in BFO2 Reference: [077-002])}}
%
as entry point for its process concepts. It is sub-classed by %
	\class{bfo:Process}\foottt{bfo:Process definition: \enquote{p is a process = Def. p is an occurrent that has temporal proper parts and for some time t, p s-depends\_on some material entity at t. (axiom label in BFO2 Reference: [083-003])}},
%
	\class{bfo:Process\_Boundary}\foottt{bfo:Process\_Boundary definition: \enquote{p is a process boundary =Def. p is a temporal part of a process and p has no proper temporal parts. (axiom label in BFO2 Reference: [084-001])}},
%
	\class{bfo:Spatiotemporal\_Region}\foottt{bfo:Spatiotemporal\_Region elucidation: \enquote{A spatiotemporal region is an occurrent entity that is part of spacetime. (axiom label in BFO2 Reference: [095-001])}}, and
%
	\class{bfo:Temporal\_Region}\foottt{bfo:Temporal\_Region elucidation: \enquote{A temporal region is an occurrent entity that is part of time as defined relative to some reference frame. (axiom label in BFO2 Reference: [100-001])}}, to enable it to distinguish between the process itself and its temporal parts. \cite[p.\,66--68]{smith2015basic} Looking closer at the given examples\foottt{bfo:Process example of usage:
	\begin{inparaenum}
		\item a process of cell-division,
		\item a beating of the heart,
		\item a process of meiosis,
		\item a process of sleeping,
		\item the course of a disease,
		\item the flight of a bird,
		\item the life of an organism,
		\item your process of aging.
	\end{inparaenum}
} for \class{bfo:Process} further emphasizes the classes high-level nature. \gls{gfo} uses the high-level term \textit{Temporal Complexes} to denote the \enquote{most general kind of concrete individuals which have a temporal extension} \cite[p.\,26]{herre2010general}, which includes processes: \enquote{The set of processes is a proper subset of the set of connected temporal complexes.} \cite[p.\,27]{herre2010general}. In the ontology, the class %
	\class{gfo:Processual\_Structure}\foottt{gfo:Processual\_Structure dc:description: \enquote{The category of processual structures centers around the more intuitive notion of processes. It captures processes themselves and occurrents, i.e., primarily structures of several other kinds that can be derived from processes.}}
%
represents its entry point. It is sub-classed by %
	\class{gfo:Occurent}\foottt{gfo:Occurent dc:description: \enquote{The category of occurrents comprises several categories that can be derived from processes.}}
%
and %
	\class{gfo:Processes}\foottt{gfo:Processes dc:description: \enquote{Processes are directly in time, they develop over and unfold in time. Processes have characteristics which cannot be captured by a collection of time boundaries. In particular, processes exhibit internal coherence.}}.

\gls{gist} is also not directly applicable, since it does not account for processes. It also deals with time on a comparatively high level with the class %
	\class{gist:Event}\foottt{gist:Event rdfs:comment: \enquote{Something happening over some period of time, often characterized as some kind of activity being carried out by some person, organization, or software application.}} %
that uses \class{gist:Time\_Instant} to specify start and end of the event. However, even though it is not useful for our \textit{process} model, \gls{gist} offers an intuitive approach for the other time-related concepts that we can apply to our ontology, namely \textit{tasks} and \textit{projects}: A %
	\class{gist:Project}\foottt{gist:Project rdfs:comment \enquote{A project is a task (usually a longer duration task) made up of other tasks.}} %
is considered a longer duration task that is made out of a number of other %
	\class{gist:Tasks}\foottt{gist:Task rdfs:comment: \enquote{A task which has been defined and either scheduled or accomplished, or both.}}. %
\class{gist:Project} is \relation{subclassOf} \class{gist:Task} is \relation{subclassOf} \class{gist:Event}.

\gls{fibo} also does not offer a process model. It has the class \class{fibo:Time\_Instant} as overlap with \gls{gist}. Additionally it offers \class{fibo:Time\_Interval} and \class{fibo:Time\_Direction}. However, their sub-classes---for \class{fibo:Time\_Instant}: \class{fibo:Date}, \class{fibo:Date\_Time}, \class{fibo:Date\_Time\_Stamp} and for \class{fibo:Time\_Interval}: \class{fibo:Calendar\_Period}, \class{fibo:Duration}, \class{fibo:Date\_Time\_Stamp}, \class{fibo:Recurrence\_Interval}---make it clear, that it focuses more on accurately modeling calendar dates and operations, instead of procedures.

\gls{doap} does not reference processes at all.




\subsection{Structure of the Class Hierarchy}
\label{process-subclass}
Processes need special attention when implementing them in a domain ontology, since their nature is quite different from other classes that represent physical, \eg \class{Document}, or intuitive concepts, \eg \class{Person}. As mentioned in section \ref{classes}, the built in \relation{subclassOf} relation of the class hierarchy already carries semantic meaning, that is generally not applicable to processes. For example: a \class{Delivery\_Process} may involve a \class{Food\_Preperation\_Process} as a procedural step. However, it is easy to see and understand that a \class{Food\_Preperation\_Process} is $\underline{not}$ \relation{subclassOf} a \class{Delivery\_Process} and therefore should not inherit its properties.

To model processes correctly, one could consider introducing a class like \class{*\_Process\_Part} (in the given example: \class{Delivery\_Process\_Part}) and use it to collect and connect sub-processes to their parent process. However, this results in many additional \textit{helper} classes in the class hierarchy, since every level of sub-processes requires another \class{*\_Process\_Part} class. This makes the class hierarchy harder to read and understand, since the process structure is encoded in these helper classes.

Another solution is the use of a root \class{Process} class to collect all processes and the relation \relation{isProcessPartOf}\footnote{Inverse: \relation{hasProcessPart}.} to connect a sub-process to its parent process. This results in a completely flat structure of the class hierarchy: every process is directly \relation{subclassOf} \class{Process}, independent from the level of abstraction.

\subsection{Ordering of Processes}
Another aspect that has to be discussed is the ordering of processes.

Processes are a concept that heavily relies on abstraction. The right level of abstraction depends on the use case.

\begin{compactenum}
	\item It is hard to create a complete process diagram/describe a complete process
	\item A successful process model relies on the correct
	\item Besides from the problem of completeness, if you go on the lowest level of abstraction ordering the steps become easier (true?!)
	\item Trying to create a generally applicable domain ontology brings up an interesting questions in regards to process concepts: what is the correct level of abstraction and is it possible to bring certain processes in the correct order
	\item It is therefore necessary to look at every process and its parts -- and discuss if 1) correct level of abstraction 2) can it be ordered
	\item A parent process aggregates child process

	\item When discussing the lowest level of a process Depending on the level of abstraction,
	\item Indepentendt from the class hierarchy problem, another topic: The procedural information is encoded in the relation.
	\item Processes are a sequence of action -> but not always
	\item there should be a next\_process relation, but it's not straight forward, since there is not necessarily a strict ordering.
	\item introduce a non strict ordering?
\end{compactenum}

\subsection{Discreet Events and Liquid Processes}

\begin{compactenum}
\item In addition to that a distinction has to be made between \textit{discreet} events and \textit{liquid} processes. \cite[p.\,447]{Russell:2010aa}
\item Processes are an immaterial concept that is strongly connected to relations of relative time, such as \relation{before} and \relation{after}.
\end{compactenum}




\subsection{Legal Requirements in the Processes}
\glspl{sco} are organizations in the social context; German law applies to them, like it applies to every other German organization. It influences their structure and processes. However, discussing the impact of the law onto internal workings of an organizations would go far out of scope of this work. Therefore the ontology omits a detailed description of the legal obligations, but references them abstractly where it is necessary.

For example: German law requires every company to pay taxes on their earnings. Depending on the \gls{sco} and the way projects are handled, this influences the process that is concerned with taxation. To develop a perfectly correct model, a very detailed discussion of specific processes would be required; this is out of scope. However, interacting with the tax authorities and learning about and filing the correct paper work is an important part of the learning experience for student consultants. It is therefore important for the ontology. To address this fact, but keep the ontology focused, it is condensed into the class \textit{Project Taxation Process} as part of the \textit{Project Process}.


%\subsection{Conclusion: Processes in this Work}
They intuitively have a start, duration, and end.

Since the focus of the ontology is on simplicity, we decide to use a single  class \class{Process} as root for all processes in conjunction with the \relation{isProcessPartOf} relation. This method utilizes the core concepts of ontologies, classes and relations, and avoids encoding extra information in unconventional ways. To compensate for the resulting un-intuitive flat class hierarchy, we add diagrams to describe the processes and their relationships graphically (see appendix \ref{process-diagrams}).

%\subsubsection{Intuitive Look}
The primary goal of an \gls{sco} is teaching students project work. They reach this goal by training their members and offering them opportunities to work on real-world projects. Looking at this from a high-level process perspective, this can be boiled down to distinct steps that have to be performed by the organization:

\begin{compactitem}
	\item Members have to be recruited.
	\item Members have to be taught the necessary skills, to be able to work on projects.
	\item Projects have to be acquired.
	\item Projects have to be worked on by members.
\end{compactitem}

Additionally these steps have various amount of support processes that help facilitate them, \eg technical and legal support.

%\subsubsection{Comparison with Process Documentation}
Conflating this intuitive view results in two complex processes that are commonly know in the business world \cite{CN} and are also present in the available process documentation \cite{hc-prozesshandbuch}:
\begin{compactenum}
	\item A \gls{hrp}, that focuses on the recruitment, training, and generally enabling of human beings (or in the case of \glspl{sco}: Members).
	\item A \gls{pp}, that documents the way an organization handles projects from start to finish.
\end{compactenum}

Again, both processes are influenced by the context switches discussed in section \ref{context-switches}. On the one hand, they can be viewed as an individual instance for one of the main protagonists of the process. On the other, they can viewed as the process of the organization. Example:
\begin{compactitem}
	\item The main protagonist of the HRP is one individual student. This individual student is following one instance of the HRP; this instance does not have to be identical with the instance of a second individual student, nor with the planned process of the organization. Both individuals might do different educational courses, hold different business ranks within the organization, or might be at different points in time of their career.
	\item The \gls{sco} itself has a HRP. It structures important aspects of the organization such as the career path. It describes the complete path from recruitment of a new member to offboarding at the end of the membership. Most importantly this process describes the plan on an abstract level and knowingly omits parts of the real world process that are not important to the organization.
\end{compactitem}


\chapter{Student Consulting Organizations: The Ontology \progressbar[filledcolor=red]{0.2}}
\section{Scope of the Domain \progressbar[filledcolor=green]{0.8}}
\label{competency-questions}
\subsection{What is the domain that the ontology will cover?}
\glspl{sco} are a form of consulting firms.  They can be compared to small consulting businesses, but are staffed -- most of the time exclusively -- by students. In other countries, \eg in France and Brazil, they are also referred to as \href{https://en.wikipedia.org/wiki/Junior_enterprise}{\textit{Junior Enterprises}} (JE). In Germany they are usually a registered association (German: \textit{Verein}) and/or a group associated with a specific university (German: \textit{Hochschulgruppe}). They aim to teach students about consulting as a profession by providing a platform that educates and trains students in the craft and provides them with the organizational means to work on consulting projects.

The domain is a specialization of the a classical consulting firm. It differs especially in terms of professionalization, since companies are focused on profit using education as the means, whereas \glspl{sco} focus on the educational aspect and on providing experience, while having profit as secondary goal.

\subsection{For what we are going to use the ontology?}
This ontology is a contribution to the knowledge management of \glspl{sco}. It can be used to learn or teach about the domain. It can also be used as a starting point for projects that require a model of the domain.

\subsection{For what types of questions the information in the ontology should provide answers?}
The ontology serves as an abstract description of the \gls{sco} domain. It defines all classes and relations that are typically present in this type of organization. Therefore it can answer questions like:
\begin{itemize}
	\item What processes exist and are required in an \gls{sco}?
	\item What roles exist and have to be filled in an \gls{sco}?
\end{itemize}

\subsection{Who will use and maintain the ontology?}
The users of this ontology are the leadership of \glspl{sco} in Germany as well as the leadership of the \gls{sco} umbrella organizations. The release version coincides with the finalization and grading of this work. If the ontology sees use by the target group, it will be maintained by the author. Access will be publicly provided on a GitHub repository. It is considered a living document, hence not necessarily complete until otherwise stated. Contributions and forks will be possible via the GitHub interface.

\section{Classes}
\subsection{Agent}
\begin{compactitem}
\item Agent
	\begin{compactitem}
	\item Group
		\begin{compactitem}
			\item Executive\_Board
			\item Member\_Assembly
			\item Project\_Team
		\end{compactitem}
	\item Organization
		\begin{compactitem}
			\item Student\_Consulting\_Organization
			\item Umbrella\_Organization
			\item University
		\end{compactitem}
	\item Person
		\begin{compactitem}
			\item Member
				\begin{compactenum}
					\item Consultant
					\item Junior\_Consultant
					\item Senior\_Consultant
					\item Trainee
				\end{compactenum}
		\end{compactitem}
	\end{compactitem}
\end{compactitem}
% TODO: Syntactic decision: is/has relations

% TODO: Verify ($\diamond$ means the relation is implemented in the ontology)

\textbf{Agent}
\begin{compactitem}
	\item All members except trainees and almunus can be corporate officers $\diamond$
	\item Non-members can't become corporate officers $\diamond$
	\item Members can play project team roles $\diamond$
	\item Every agent can play the customer role in a project $\diamond$
	\item Every member goes through his individual HRP
	\item An organizational rank has tbd requirements
	\item Customer, Team, Contract, etc are \textbf{part of} a project
	\item Organizations can only \textbf{play} the customer \textbf{role} in a project $\diamond$
	\item Organization can only play external roles $\diamond$
\end{compactitem}

\textbf{Processes}
\begin{compactitem}
	\item All processes have a \textbf{next\_process} $\diamond$
	\item \textbf{previous\_process} should be inferred?!
	\item
\end{compactitem}

before/after:
\begin{compactitem}
	\item FIBO: relates to -> precedes/succeeds?
	\item plays role
\end{compactitem}


\chapter{Conclusion}
\chapter{Further Research}

\appendix
\chapter{Appendix}
\section{Term Enumeration}
\label{word-cloud}

\newpage
\section{Diagrams}
\subsection{General Diagrams}
% TODO: Add correct relation

\begin{figure}[h]
	\caption{Ranks}
	\centering
	\includegraphics[width=1\textwidth]{Diagrams/ranks.pdf}
\end{figure}

\begin{figure}[h]
	\caption{Corporate Officers}
	\centering
	\includegraphics[width=1\textwidth]{Diagrams/corporate-officers.pdf}
\end{figure}


\clearpage
\subsection{Process Diagrams}
\label{process-diagrams}
\begin{figure}[h]
	\caption{Project Process}
	\centering
	\includegraphics[width=1\textwidth]{Diagrams/project-process.pdf}
\end{figure}

\begin{figure}[h]
	\caption{Human Resources Process}
	\centering
	\includegraphics[width=1\textwidth]{Diagrams/hr-process.pdf}
\end{figure}

\clearpage
\printnoidxglossaries

\printbibliography

\newpage

\section{Dictionary Definitions}
\label{dictionary}
% \textcolor{gray}{\textit{\enquote{}}}

\begin{mdframed}[%
	linewidth=1pt,%
	frametitlerule=true,%
	frametitlebackgroundcolor=gray!20,%
	innertopmargin=\topskip,%
	frametitlefont=\normalfont,%
	frametitle={{\textbf{context}} {\scriptsize\textsc{noun \hfill Merriam-Webster}}}%
	]
	
	{\small con·​text
		\begin{compactenum}
			\item the parts of a discourse that surround a word or passage and can throw light on its meaning
			\item the interrelated conditions in which something exists or occurs : ENVIRONMENT, SETTING \\
			\textcolor{gray}{\textit{\enquote{the historical context of the war}}}
		\end{compactenum}
	}
\end{mdframed}

\begin{mdframed}[%
	linewidth=1pt,%
	frametitlerule=true,%
	frametitlebackgroundcolor=gray!20,%
	innertopmargin=\topskip,%
	frametitlefont=\normalfont,%
	frametitle={{\textbf{domain}} {\scriptsize\textsc{noun \hfill Merriam-Webster}}}%
	]
	
	{\small do·​main
			\begin{compactenum}
				\item law
				\begin{compactenum}
					\item complete and absolute (see absolute sense 3) ownership of land \\
					\textcolor{gray}{\enquote{\textit{our highways and roads have been in the domain of state and local governments— T. H. White b. 1915}}} \\
					 — compare EMINENT DOMAIN
					\item land so owned
				\end{compactenum}
				\item a territory over which dominion (see DOMINION sense 2) is exercised \\
				\textcolor{gray}{\enquote{\textit{The forest is part of the king's domain.}}}
				\item a region distinctively marked by some physical feature \\
				\textcolor{gray}{\enquote{\textit{a domain of rushing streams, tall trees, and lakes}}}
				\item a sphere (see SPHERE sense 4b) of knowledge, influence, or activity \\
				\textcolor{gray}{\textit{\enquote{the domain of biblical scholarship}, \enquote{outside the domain of city police}}}
				\item mathematics : the set of elements (see ELEMENT sense 2b(3)) to which a mathematical or logical variable is limited \\
				specifically : the set on which a function (see FUNCTION entry 1 sense 5a) is defined
				\item physics : any of the small randomly oriented regions of uniform magnetization in a ferromagnetic substance
				\item mathematics : INTEGRAL DOMAIN
				\item biology : the highest taxonomic category in biological classification ranking above the kingdom (see KINGDOM sense 4b)
				\item biochemistry : any of the three-dimensional subunits of a protein that are formed by the folding of its linear peptide chain and that together make up its tertiary (see TERTIARY entry 1 sense 3c) structure
				\item computers : a subdivision of the Internet consisting of computers or sites usually with a common purpose (such as providing commercial information) and denoted in Internet addresses by a unique abbreviation (such as com for commercial sites or gov for government sites) \\
				\textcolor{gray}{\textit{\enquote{The domain ca is used for sites located in Canada.}}} \\
				also : DOMAIN NAME \\
				\textcolor{gray}{\textit{\enquote{Our domain is Merriam-Webster.com.}}}
		\end{compactenum}
	}
\end{mdframed}

\begin{mdframed}[%
	linewidth=1pt,%
	frametitlerule=true,%
	frametitlebackgroundcolor=gray!20,%
	innertopmargin=\topskip,%
	frametitlefont=\normalfont,%
	frametitle={{\textbf{vocabulary}} {\scriptsize\textsc{noun \hfill Merriam-Webster}}}%
	]
	
	{\small vo·​cab·​u·​lary \textit{\textcolor{teal}{plural}} vocabularies
		\begin{compactenum}
			\item a list or collection of words or of words and phrases usually alphabetically arranged and explained or defined : LEXICON \\
			\textcolor{gray}{\enquote{\textit{The vocabulary for the week is posted online every Monday.}}}
			\item
			\begin{compactenum}
				\item a sum or stock of words employed by a language, group, individual, or work or in a field of knowledge \\
				\textcolor{gray}{\textit{\enquote{a child with a large vocabulary}}, \enquote{the vocabulary of physicians}, \enquote{a writer known for employing a rich vocabulary}}
				\item a list or collection of terms or codes available for use (as in an indexing system) \\
				\textcolor{gray}{\enquote{\textit{… the oldest Sumerian cuneiform writing could not render normal prose but was a mere telegraphic shorthand, whose vocabulary was restricted to names, numerals, units of measure, words for objects counted, and a few adjectives.}} --- \textsc{Jared Diamon}}
			\end{compactenum}
			\item a supply of expressive techniques or devices (as of an art form) \\
			\textcolor{gray}{\textit{\enquote{an impressive musical vocabulary}}}
		\end{compactenum}
	}
\end{mdframed}

\newpage
\section{Ontology Import Links}
This work lists different ontologies in the related work section. To import them into the Protégé editor, the following links can be used:

\begin{asparadesc}
	\item [\gls{bfo}:] \url{http://purl.obolibrary.org/obo/bfo/2.0/bfo.owl}
	\item [\gls{bpmn}:] \url{https://dkm-static.fbk.eu/resources/ontologies/BPMN/BPMN_2.0_ontology.owl}
	\item [\gls{doap}:] \url{http://usefulinc.com/ns/doap}
	\item [\gls{fibo}:] \url{https://spec.edmcouncil.org/fibo/ontology/master/2019Q4.1/LoadFIBOProd.rdf}
	\item [\gls{foaf}:] \url{http://xmlns.com/foaf/spec/index.rdf}
	\item [\gls{gfo}:] \url{http://www.onto-med.de/ontologies/gfo-basic.owl}
	\item [\gls{gist}:] \url{https://ontologies.semanticarts.com/o/gistCore9.0.0.owl}
	\item [\gls{schema}:] \url{http://schema.org/version/latest/schema.rdf}
\end{asparadesc}

\section{Acknowledgments \progressbar[filledcolor=green]{1}}
This work was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.

\end{document}
