main.tex

%% The first command in your LaTeX source must be the \documentclass command.
%%
%% Options:
%% twocolumn : Two column layout.
%% hf: enable header and footer.
%% The first command in your LaTeX source must be the \documentclass command.

\RequirePackage{pdf14}
\documentclass[
% twocolumn,
% hf,
]{ceurart}

%%
%% One can fix some overfulls
\sloppy

\usepackage{xcolor}   % colour support
\usepackage{listings}
\usepackage{tikz}
\usetikzlibrary{trees, positioning}
\usepackage{caption}
\usepackage{float}




% Make lstlisting use the figure counter and label style
\renewcommand{\lstlistingname}{Figure}
\makeatletter
\AtBeginDocument{%
  \let\c@lstlisting\c@figure
  \let\thelstlisting\thefigure
}
\makeatother


\lstdefinelanguage{ManchesterOWL2}{
    morekeywords={
        EquivalentTo, SubClassOf, Class, ObjectProperty, 
        DataProperty, Individual, and, or, some, only, value,
        min, max, exactly, inverse, not, that
    },
    sensitive=true,
    morecomment=[l]{\#},
    morestring=[b]",
}

\lstset{
    language=ManchesterOWL2,
    basicstyle=\ttfamily\tiny,
    keywordstyle=\bfseries,
    commentstyle=\color{gray},
    stringstyle=\color{teal},
    columns=fullflexible,
    keepspaces=true,
    breaklines=true,
}

\lstdefinelanguage{Turtle}{
    morekeywords={@prefix, a},
    sensitive=true,
    morecomment=[l]{\#},
    morestring=[b]"
}

\lstset{
    language=Turtle,
    basicstyle=\ttfamily\scriptsize,
    keywordstyle=\bfseries,
    commentstyle=\color{gray},
    stringstyle=\color{teal},
    columns=fullflexible,
    keepspaces=true,
    breaklines=true,
    frame=single,         % Draw a single-line frame
    rulecolor=\color{black},  % Frame color
    framerule=0.3pt,      % Thin frame line
    framesep=5pt         % Space between code and frame
}



%%
%% end of the preamble, start of the body of the document source.

\begin{document}
%%
%% Rights management information.
%% CC-BY is default license.
\copyrightyear{2025}
\copyrightclause{Copyright for this paper by its authors.
  Use permitted under Creative Commons License Attribution 4.0
  International (CC BY 4.0).}

%%
%% This command is for the conference information
\conference{Proceedings of the Joint Ontology Workshops (JOWO) - Episode XI: The Sicilian Summer under the Etna, co-located with the 15th International Conference on Formal Ontology in Information Systems (FOIS 2025), September 8–9, 2025, Catania, Italy}




%%
%% The "title" command
\title{SULO -- a simplified upper-level ontology}

\tnotemark[1]
\tnotetext[1]{This version corrects the presentation of the examples in
Figures~\ref{lst:solid-example}, \ref{lst:pro_odp} and \ref{lst:turtle-pro}, and
names the object property \texttt{hasItem} as SULO defines it, and therefore
differs from the version of record published in the CEUR-WS proceedings of
FOUST 2025. The corrections are listed in the paper's source
repository. No claim, result, or axiom of SULO is changed.}

%%
%% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
\author[1]{Michel Dumontier}[%
orcid=0000-0003-4727-9435,
]
\cormark[1]
\fnmark[1]


\author[1]{Remzi Çelebi}[%
orcid=0000-0001-7769-4272,
]

\author[1]{Komal Gilani}[%
orcid=0000-0001-7292-1026,
]

\author[2]{Isabelle de Zegher}[%
orcid=0000-0001-7292-1026,
]

\author[3]{Katerina Serafimova}[%
orcid=0009-0004-0797-7313,
]

\author[4]{Catalina Martínez Costa}[%
orcid=0000-0003-1857-1744,
]

\author[5,6]{Stefan Schulz}[%
orcid=0000-0001-7222-3287,
]
\fnmark[1]



\address[1]{Institute of Data Science, Department of Advanced Computing Sciences, Maastricht University, Netherlands}
\address[2]{b!loba, Tervuren, Belgium}
\address[3]{Graphwise, Sofia, Bulgaria}
\address[4]{Department of Informatics and Systems, University of Murcia, Spain}
\address[5]{Institute for Medical Informatics, Statistics and Documentation, Medical University of Graz, Austria}
\address[6]{Averbis GmbH, Germany}

\fntext[1]{These authors contributed equally.}

%% Footnotes
\cortext[1]{Corresponding author. Michel Dumontier, michel.dumontier@maastrichtuniversity.nl}


%%
%% The abstract is a short summary of the work to be presented in the
%% article.


\begin{abstract}
Ontology-based data integration remains a core challenge in healthcare and the life sciences, where the need to analyse heterogeneous datasets demands robust semantic interoperability. Upper level ontologies (ULOs) play a key role in ontology integration, by relating their concepts using common upper-level classes and relations. While ULOs offer a formal foundation for knowledge representation, their complexity often limits adoption by domain experts and standards developers unfamiliar with formal logic or ontology engineering. 
In this paper, we introduce the Simplified Upper-Level Ontology (SULO) — a lightweight framework comprising a minimal, intuitive set of classes and relations designed to support common modeling needs in biomedical terminologies, ontologies, and schemas. We introduce two ontology design patterns that systematically decompose complex predicates into reusable semantic structures grounded in SULO. We apply the patterns to represent class expressions in the SNOMED biomedical ontology, and to formalise SPHN, an RDF-based biomedical schema. Finally, we compare our approach with other upper level ontologies. The proposed approach facilitates interoperability and promotes reuse, while preserving the expressiveness necessary for rich domain modeling.
\end{abstract}

%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
\begin{keywords}
  Upper level ontology \sep
  Foundation Ontology \sep
  Formal Knowledge Representation \sep
  Knowledge Graphs \sep
  Schema
\end{keywords}

%%
%% This command processes the author and affiliation and title
%% information and builds the first part of the formatted document.

\maketitle
\section{Introduction}
\subsection{Background}
The need to capture facts and knowledge about a domain in a standardised representation has led to the development of domain-specific terminologies and ontologies. In the past three decades, the evolution of the discipline of Applied Ontology has stimulated the development of upper-level ontologies (ULOs), also known as top-level and foundational ontologies, which attempt to provide a general theory of \textit{what exists}. Examples are BFO \cite{bfo}, UFO \cite{ufo}, GFO \cite{gfo}, DOLCE \cite{dolce}, YAMATO \cite{mizoguchi2022yamato}, SIO \cite{dumontier2014semanticscience} and BioTop \cite{schulz2017biotopfamily}. 

ULOs are grounded in different metaphysical commitments and modeling styles. They are motivated by different scopes of application, e.g., BFO for natural sciences, DOLCE for linguistic and cognitive engineering, and UFO for information science. ULOs claim their usefulness as an overarching axiomatic framework for domain ontologies (DOs), which represent \textit{what exists in a specific domain}, by offering guidance on the conceptualization and formalisation of the domain, enabling automated reasoning to check conformance of the domain ontology to the ULO. However, creating alignments between domain ontologies and ULOs, and between ULOs, remains deeply challenging owing to the complexity of the task \cite{DBLP:journals/semweb/TrojahnVSPG22}. In contrast, SIO and BioTop each offer an ULO that is directly extended to their particular domains. 

Apart from terminologies and ontologies, many domain schemas have also been developed.  Even sometimes called ``ontologies'' or ``schemas'' (such as the SPHN \cite{sphn_toure2023fairification} up to 2024) or ``semantic models'' (such as CARE-SM \cite{Kaliyaperumal2022}), they do not claim the rigor of formal ontologies. They support domain data structures from a data modelling perspective rather than a domain modelling one. Finally, large terminologies and (meta)thesauri such as SNOMED CT \cite{snomed2025}, NCIT \cite{ncit2007}, and the UMLS \cite{McCray_Nelson_1995} include their own ontological or conceptual upper levels, as well as systems that are primarily intended to provide support to purpose-driven data collection, e.g. HL7v3 \cite{RIM_2016}. These upper levels have been developed based on pragmatic considerations, rather than through an ontology-driven analysis of the application domain.

%%% todo add SPHN 

\subsection{The practical use of ULOs and upper-level models}
The aim to develop interoperable and computable knowledge graphs must navigate complex choices and address various challenges posed by current upper-level distinctions and models, whether from upper-level ontologies, domain-specific upper ontologies, legacy terminology frameworks, or domain-specific schemas. 
Such decisions have to take into consideration:
\begin{itemize}
\item
The requirements include understanding nuanced philosophical considerations and familiarity with logic. Even ULO experts struggle to correctly and consistently apply the ontology in classification tasks \cite{STEVENS2019100469}. ULOs adopting particular philosophical stances such as realism facilitate some domain applications, while struggling with others \cite{realismcritique2010}\cite{Lord2010}
\item
ULOs have known missing or underrepresented areas. E.g., GFO explicitly separates universals and particulars. BFO  supports ternary relations only in its Common Logic formalisation (with time as the third argument), but refrains from a concrete time model. Not all ULOs support realizables, social entities and information entities. BFO, GFO, and DOLCE do not offer any data properties to capture literal values, e.g. numeric values characterizing measurements. 
\item
The foundational categories of ULOs and the top level of domain ontologies often use labels that carry implicit assumptions, e.g. \textit{Object}, \textit{Process}, \textit{Event}, \textit{Function}, \textit{Quality}, and \textit{Disposition}. These assumptions differ not only between models using the same labels, but also evoke varying associations among domain experts. Not always are these categories defined in precise terms, which can lead to misunderstanding and unintended modeling results \cite{STEVENS2019100469}. This is particularly true with systems that carry a strong legacy, such as SNOMED CT \cite{snomed2025} with upper-level categories labeled such as \textit{Clinical Finding}, \textit{Observable},  \textit{Qualifier Value}. They lack clear definitions, are difficult to translate and therefore difficult to map to ULOs\cite{Schulz2023SnomedBFO}. 
\item
Some ULOs deliberately adopt unfamiliar or technical labels derived from philosophical ontology such as \textit{Continuant}, \textit{Endurant}, \textit{Perdurant}, \textit{Specifically dependent continuant}. Although this approach can more precisely define terms, they may be less clear or intuitive ot a general audience. On the other hand, using terms that are broadly acceptable and reusable across fields may be interpretable diffrently in defferent disciplines.
\item
Domain ontologies often show an excess of different relation types.  To support the structuring of data graphs according to specific shapes, informal top levels often include numerous specialized but relatively unformalised relations of the form ``\textbf{hasRangeType}'', such as \textbf{hasPatient}, \textbf{findingSite},  \textbf{hasTemperature} where the range is implicitly constrained by the target class.
\end{itemize}

It is therefore no wonder that a large majority of ontologies have been created without any reference to a formalised upper level. In BioPortal, a repository of currently 1,204 biomedical ontologies, only for BFO, a significant re-use of upper-level content can be demonstrated with 138 reference to the class BFO\_0000002 (bfo:continuant), whereas references to other ULOs are in the low single-digit range. A study published in 2017 had analyzed 355 ontologies hosted in BioPortal and found that 21\% of them had imported one or more BFO classes \cite{ochs2016}. 


\section{Proposal: A Simplified Upper-Level Ontology (SULO)}
Towards addressing the aforementioned issues, we propose SULO (\textit{Simplified Upper-Level Ontology}), an upper level ontology that takes a minimalistic approach to guide the alignment, formalisation, and reusability of upper level and domain ontologies. SULO attempts to balance formal rigour with simplicity and practical usability. This is achieved by reducing the number of upper-level classes and relations to an absolute minimum while maintaining compatibility with existing ULOs, domain ontologies, and hybrids that fuse elements of terminologies, ontologies and schemas. We hypothesize that such a minimized ULO will foster adherence to intended semantics by domain specialists. 

SULO aims to reconcile expressivity with usability addressing the following principles:
\begin{itemize}
\item \textbf{Minimalism}: SULO proposes a small taxonomy of disjoint classes and a minimal set of constrained relations to ensure broad applicability across domains.
\item \textbf{Compatibility}: SULO maintains compatibility with core components of well-known ULOs while remaining accessible to domain experts. It does not claim to compete with established ULOs but claims to serve as a compatibility layer 
%an umbrella above 
between established ULOs.
\item \textbf{Accessibility}: SULO aims to be accessible to users with no or little training in formal ontology through friendly labeling, a simple taxonomy, and a general overview that fits in a single diagram.
\item \textbf{Composability}: SULO will provide the building blocks to construct complex, machine-readable class expressions.
\item \textbf{Interoperability}: SULO fosters interoperability by providing a common semantic foundation, including two ontology design patterns, that help domain experts adhere to explicit an implicit semantics.
\item \textbf{Data validation}: SULO constrains real-world knowledge graphs through automated reasoning and schema validation. 
\end{itemize}

These principles support a flexible framework for aligning and integrating biomedical data representations and standards, by offering a basic ordering principle for knowledge representation assets in a domain. It can be seen as a low-threshold entry into principled domain modeling, without requiring engagement -- at least in initial iterations -- with ontological and logical intricacies, such as those 
%imposed by formal ULOS. 
imposed by more fine-grained and expressive ULOs.

\section{Methods}
We followed the NEON methodology \cite{suarez2011neon}, consisting of i) domain analysis, ii) requirement gathering, iii) development of modular and pattern-based designs, iv) alignment with standards and existing ontologies, iv) iterative development and validation, and v) integration and maintenance. 
SULO development was initiated at a workshop with six participants, three of whom had strong ontology engineering expertise, three with domain expertise and specific use cases, two being ETL developers, and one being a high-level domain expert. The domain analysis was primarily drawn from the functional requirements in the AIDAVA project \cite{deZegher2024}, which targets the rendering of healthcare processes as knowledge graphs rooted in semantic standards, and which currently uses the SPHN schema\cite{sphn_toure2023fairification} to create personal health knowledge graphs from heterogeneous data sources, as well from challenging formalisation use cases drawn from SNOMED-CT. The workshop participants discussed key approaches adopted by existing ULOS, and set out to identify a minimal and accessible set of classes, relations and design patterns to cover key use cases (namely plans and processes around heart transplantation, fractured femurs, and in admission and discharge of patients in a hospital setting. Participants discussed at candidate classes and relations, mapped these to existing ULOs, and proposed possible simplifications that could form the basis of the SULO. The in-person workshop was followed by four additional online workshops for further iterative development, discussion, and validation involving over two dozen biomedical phenomena. 
The project is on github\footnote {\url{https://github.com/AIDAVA-DEV/sulo}; with the namespace \url{https://w3id.org/sulo/} and an OWL/Turtle representation at \url{https://w3id.org/sulo/sulo.ttl}}, where syntax and consistency are automatically checked using Raptor and Robot with Hermit, and HTML documentation is generated using Ontospy \cite{ontospy} and PyLODE \cite{pylode}.  


\section{Results}
% \todo[inline]{We should use the same formatting: bold for OWL individuals and properties, italics for classes. \\
% Symbols that contain spaces should be enclosed by single quotes } 

\subsection{SULO Overview}
SULO is implemented as an OWL2 ontology using Protege. It comprises 17 classes, 18 object properties (9 inverse properties), and 1 data property. An overview of the classes and relations can be seen in Figure \ref{fig:sulo_overview}, and are further described in this section.

\begin{figure}[h!]
    \centering
    \captionsetup{justification=centering, singlelinecheck=false}
    \includegraphics[width=1\textwidth]{sulo-overview.png}
    \caption{Graph representation of SULO classes and properties. Solid lines indicate domain and range of properties, while dotted lines indicate their use in class axioms.}
    \label{fig:sulo_overview}
\end{figure}

\subsection{SULO classes}
SULO comprises seven taxonomic levels, which are mutually disjoint at each level (see Figure \ref{fig:sulo-class-tree}). 


\begin{figure}[h!]
\centering
\begin{tikzpicture}[
  level distance=0.8cm,
  sibling distance=2.5cm,
  every node/.style={font=\small, align=center},
  edge from parent path={(\tikzparentnode.south) -- (\tikzchildnode.north)},
  grow=down
]

\node {owl:Thing}
  child { node {Process} }
  child { node {Object}
    child { node {SpatialObject} }
    child { node {Feature}
    child { node {Role} }
      child { node {Quality} }
      child { node {Capability} }
      child { node {InformationObject}
        child { node {Collection} }
        child { node {Quantity}
          child { node {Time}
            child { node {Duration} }
            child { node {TimeInterval} }
            child { node {TimeInstant}
              child { node {StartTime} }
              child { node {EndTime} }
            }
          }
          child { node {Unit} }
        }
      }
    }
  };

\end{tikzpicture}
\caption{Taxonomy of SULO classes.}
\label{fig:sulo-class-tree}
\end{figure}



\par
A \textit{Process} has temporal parts, unfolds in time, has a duration and has objects as participants (\textit{e.g. the life of an organism, a heart transplant, the administration of medication}). Processes that have temporal parts are fully determined when the last part of the process is finished. 
% For instance, a successful heart transplant process would include a sequence of temporal parts: opening the chest, establishing extracorporeal circulation, the extraction of the heart, the implantation of the heart, the restitution of circulation, and finally, the closing of the chest. Let \textit{p} be a \textit{Process}, only after the instantiation of the last temporal part of a \textit{Heart Transplant}, \textit{p} can be asserted as being an instance of \textit{Heart Transplant}. 

\par
An \textit{Object} maintains its identity through time, does not have processes as its parts, but participates in processes. Objects are dichotomized into \textit{SpatialObject} (e.g. a person, a particle, a paper document, a hospital) and \textit{Feature}. A \textit{SpatialObject} exists in space and can be characterised in one ore more dimensions of spacetime. They can gain and lose parts and their features can change over time. A \textit{Feature} is an object that existentially depends on other things, whether objects or processes. The class \textit{Feature} includes \textit{Quality} (e.g. the redness of an apple), \textit{Role} (e.g. the role of a care subject, a care provider, a student or a blood donor), \textit{Capability} (e.g. the capability to breathe or to produce offspring), as well as \textit{InformationObject} (e.g. the content of a document, a clinical practice guideline, a mathematical formula). 

An \textit{InformationObject} is a \textit{Feature} whose existence depends on and is about something. Two subclasses of \textit{InformationObject} are introduced, \textit{viz.} \textit{Collection} %%\textit{Collection} 
%% theory on collectives https://journals.sagepub.com/doi/epdf/10.3233/AO-2009-007
and \textit{Quantity}. A \textit{Collection} is an \textit{InformationObject} pertaining to classes and mathematical sets, while a \textit{Quantity} is an \textit{InformationObject} that captures a numerical aspect (of an attribute) with a value and optional \textit{Unit}, and is further divided into two subclasses \textit{Time} and \textit{Unit}.  In SULO, \textit{Time} is a \textit{Quantity} - it is a measurement of time (it does not offer an ontology of time). SULO's \textit{Time} class is divided into 3 subtypes: a \textit{TimeInstant}, \textit{TimeInterval}, and \textit{Duration} of time. \textit{StartTime} and \textit{EndTime} are role-playing \textit{TimeInstant} that are useful in demarcating the boundaries of a \textit{Process} or \textit{TimeInterval}.


\subsection{SULO relations}
SULO offers 18 object properties (9 direct + 9 inverses) and one data property. 

\begin{figure}[h!]
\centering
\begin{tabular}{c@{\hspace{0cm}}c}
% First tree: Object properties
\Tree [.owl:TopObjectProperty 
        [.isIn 
            [.isPartOf 
                [.isDirectPartOf ]
            ] 
        ]
        [.atTime ]
        [.precedes ]
        [.hasParticipant ]
        [.hasFeature ]
        [.refersTo ]
        [.hasItem ]
    ]
&
% Second tree: Data properties
\Tree [.owl:TopDataProperty 
        [.hasValue ]
    ]
\end{tabular}
\caption{Taxonomy of SULO object and data properties.}
\label{fig:sulo-object-property-tree}
\end{figure}




\subsubsection{Space and Time}
SULO does not explicitly admit or refer to spatial or temporal regions, rather it focuses on associating entities with where they are located and at what time they exist. {\ttfamily\bfseries isIn} (inverse: {\ttfamily\bfseries contains}) is a \textit{transitive} binary relation where the object includes the subject within its spatial, temporal, structural, or conceptual extent. The {\ttfamily\bfseries atTime} (inverse: {\ttfamily\bfseries isTimeOf}) relation holds between any entity and a time measurement. It captures the notion of {\tt when} in time something exists or occurs. The {\ttfamily\bfseries precedes} relation holds between two distinct processes, $p1$ and $p2$, indicating that $p1$ ends before $p2$ begins. It captures strict temporal ordering and sequential relationships between processes.

% incorporated within the particular entity $y$, either spatially, tempo conceptually, or informationally. 
\subsubsection{Parthood}
The {\ttfamily\bfseries isPartOf} (inverse: {\ttfamily\bfseries hasPart}) relation is a \textit{transitive} and \textit{reflexive} relation expressing that entity $x$ is incorporated within the entity $y$, where $x$ contributes to the composition or structure of $y$  in such a way that removing $x$ from $y$ would change the integrity or identity of $y$. The relation does not have a reference to time, and as such indicates the notion that $x$ {\ttfamily\bfseries isPartOf} $y$ during some \textit{Time} $t$. Examples include \textit{myLeftVentricle} {\ttfamily\bfseries isPartOf} \textit{myHeart}, \textit{this administration of ibuprofen} {\ttfamily\bfseries isPartOf} \textit{treatment of my headache},  \textit{this premise} {\ttfamily\bfseries isPartOf} \textit{that argument}. The {\ttfamily\bfseries isDirectPartOf} (inverse: {\ttfamily\bfseries hasDirectPart}) relation is a non-transitive subrelation of {\ttfamily\bfseries isPartOf} to specify cardinality constraints in an OWL class expression. This relation is needed because OWL 2 does not allow cardinality constraints over transitive relations. {\ttfamily\bfseries hasDirectPart} is the inverse relation of {\ttfamily\bfseries isDirectPartOf}. An example class expression is \textit{Human Heart} {\tt subClassOf} \textit{SpatialObject} \textit{that} {\ttfamily\bfseries hasDirectPart} \textit{exactly 2} \textit{Ventricle}.

\subsubsection{Descriptors}
The {\ttfamily\bfseries hasFeature} (inverse: {\ttfamily\bfseries isFeatureOf}) relation holds between any entity and a \textit{Feature}. For instance, a three-dimensional \textit{SpatialObject} is associated with the \textit{Quality} of \textit{Volume}, which may be measured and reported as a \textit{Quantity} {\ttfamily\bfseries atTime} \textit{Time}.

\subsubsection{Participation in Processes}
The {\ttfamily\bfseries hasParticipant} (inverse: {\ttfamily\bfseries isParticipantIn}) relation holds between a \textit{Process} and an \textit{Object}. We capture the notion that when a \textit{Feature} participates in a \textit{Process}, then so does the \textit{Object} for which it is a \textit{Feature} of through the role chain {\ttfamily\bfseries hasParticipant} o {\ttfamily\bfseries isFeatureOf} $\rightarrow$ {\ttfamily\bfseries hasParticipant}. A key design pattern is to represent the different roles that objects play in a particular process. For instance, the \textit{Process} of \textit{Administration of Medication} might involve one individual playing a \textit{Care Provider Role}, which administers the medication to another individual playing a \textit{Care Subject Role}. 

\subsubsection{Relations for information objects}
An \textit{InformationObject} always {\ttfamily\bfseries refersTo} (inverse: {\ttfamily\bfseries isReferredToIn}) some other thing it mentions, describes, represents or otherwise is information about. The {\ttfamily\bfseries hasValue} relation is a functional data property to capture a single literal associated with an \textit{InformationObject}. No other data property is admitted. The {\ttfamily\bfseries hasItem} (inverse: {\ttfamily\bfseries isItemIn}) relation holds between a \textit{Collection} and the items that constitute this collection.  Finally, the physical representation of an \textit{InformationObject} to a \textit{SpatialObject} can be indicated with the {\ttfamily\bfseries isFeatureOf} relation. 

\subsection{SULO Design Patterns}
To foster semantic interoperability across domain-specific knowledge representations, SULO emphasizes a set of ontology design patterns (ODPs) towards structuring data graphs to a limited set of interoperable shapes. Upper level ontologies, domain ontologies, and schemas often include numerous specialized relations of the form ``\textbf{hasRangeType}'', such as \textbf{ hasPatient}, \textbf{findingSite}, \textbf{hasTemperature} where the range is implicitly constrained by the target class. However, there are several problems with these. First is that they lead to a proliferation of relations which complicates the alignment between relations from different ontologies. Moreover, if the modeler wants to constrain the value range to something other than what is defined, they would create yet another relation and place a range constrain. Second, many such relations are just a range specialization of an existing property, and otherwise add no additional semantics. Third, such relations are simply shortcuts that bypass good modeling practice, namely the alignment of the data graph to that constrained by the upper level ontologies, thereby potentially introducing modeling errors that would otherwise be detectable through automated reasoning. We propose two design patterns that help domain modelers align their data to SULO ontology. The first design pattern, SOLID, focuses on data relations, while the second, PRO, focuses on roles that objects play in particular situations.

% http://purl.obolibrary.org/obo/DRON_00000028 'active ingredient'

\subsubsection{SOLID (Single Object Literal Information Datum) Design Pattern}
The SOLID pattern uses SULO's single functional datatype property, {\ttfamily\bfseries hasValue}, to assign a literal value to an instance of an \textit{InformationObject}. This pattern transforms the introduction of domain-specific data properties such as {\ttfamily\bfseries hasTemperature} by first extracting the implied classes (e.g., \textit{Temperature}) that pertain to a relevant \textit{InformationObject}, and secondly finding the right relation to associate the information object to either a process or an object. Consider the application of the SOLID ODP represent the temperature of an individual (Figure \ref{lst:solid-example}). Instead of using arbitrary relations such as {\ttfamily\bfseries hasTemperature} or {\ttfamily\bfseries hasTemperatureInCelcius}, the design pattern reuses SULO's {\ttfamily\bfseries hasValue} data property, {\ttfamily\bfseries hasFeature}, {\ttfamily\bfseries refersTo} and {\ttfamily\bfseries hasPart} object properties in conjunction with two externally defined classes, namely \textit{Temperature} from PATO and \textit{Celcius} from the Unit Ontology. This now becomes a proper SULO compatible description that allows for further statements (e.g. that the temperature measurement was performed using a particular device, in a particular place and time, etc). Thus, SOLID pushes the semantics out of data properties into instances of relevant classes, facilitating more elaborate descriptions now, or in the future. Moreover, the implementation of the pattern ensures a predictable location for where data values are stored, allowing for predictable querying of the {\ttfamily\bfseries hasValue} data property.

%% make listing
\begin{lstlisting}[language=Turtle, caption={Using the SOLID pattern to represent Alice's temperature of 37.8C}, captionpos=b, label={lst:solid-example}]
@prefix sulo:   <https://w3id.org/sulo/> .
@prefix uo: <http://purl.obolibrary.org/obo/> .
@prefix pato: <http://purl.obolibrary.org/obo/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://example.org/> .

:alice a sulo:SpatialObject, :Person;
    sulo:hasFeature :alice_temperature_measurement_1 .
    
:alice_temperature_measurement_1 a sulo:Quantity;
    sulo:hasValue "37.8"^^xsd:double ;
    sulo:refersTo [ a pato:PATO_0000146] ; # the quality of temperature
    sulo:hasPart [ a uo:UO_0000027 ] . # the celcius unit
\end{lstlisting}


\subsubsection{PRO (Process-Role-Object) Design Pattern}
The Process-Role-Object (PRO) ODP provides a modular way to represent how (non-process) entities participate in processes through their specific roles. The pattern, expressed as a Manchester Syntax\cite{ManSyn2012} class expression in Figure \ref{lst:pro_odp} requires that particular roles are directly linked to a process instance using {\ttfamily\bfseries hasParticipant} and to their respective role holders using {\ttfamily\bfseries isFeatureOf}: 

\begin{lstlisting}[language=ManchesterOWL2, label={lst:pro_odp}, caption={Process-Role-Object Ontology Design Pattern}, captionpos=b]
EquivalentTo:
  Process and
      hasParticipant some (
          Role and isFeatureOf some Object
      )
\end{lstlisting}

We recover the participation of the role holder by inference through a role chain (Figure \ref{lst:pro_role_chain}): 

\begin{lstlisting}[language=ManchesterOWL2, label={lst:pro_role_chain}, caption={PRO Role Chain for Inference}, captionpos=b]
hasParticipant o isFeatureOf -> hasParticipant
\end{lstlisting}

This pattern is key to discriminating the roles or functions of multiple, interacting entities in the same process. Consider a scenario in which a care provider (Dr. Smith) attends to a subject of care (Alice) to discuss Alice's condition (Listing~\ref{lst:turtle-pro}). Applying the PRO pattern, the health care encounter (\textit{encounter} is a \textit{Process}) in which the two instances of roles (\textit{alice\_subject\_of\_care\_role}, \textit{smith\_care\_provider\_role}) instantiating \textit{'patient role'} and \textit{'health care provider role'} are added as specific participants. The two roles are related to their role holders, alice and drsmith, respectively. Reasoning over this graph using the role chain, we obtain two additional triples, \textit{encounter} has \textit{alice} and \textit{drsmith} as participants.


\begin{lstlisting}[language=Turtle, caption={Inference on exemplar data graph using PRO design pattern}, captionpos=b, label={lst:turtle-pro}]

@prefix sulo: <https://w3id.org/sulo/> .
@prefix obo: <http://purl.obolibrary.org/obo/> .
@prefix : <http://example.org/> .

:encounter a sulo:Process, obo:OGMS_0000097 ; # health care encounter
    sulo:hasParticipant :alice_subject_of_care_role, :smith_care_provider_role .
    
:alice_subject_of_care_role a sulo:Role, obo:OMRSE_00000011 ; # patient role
    sulo:isFeatureOf :alice .

:smith_care_provider_role a sulo:Role, obo:OMRSE_00000012 ; # health care provider role
    sulo:isFeatureOf :drsmith .

:alice a sulo:SpatialObject, obo:NCBITaxon_9606 . # human
:drsmith a sulo:SpatialObject, obo:NCBITaxon_9606 . # human

### inference from PRO role chain
:encounter sulo:hasParticipant :alice, :drsmith .
\end{lstlisting}
Thus, the PRO pattern combined with the PRO role chain allows a clear mechanism by which dynamic, context-dependent roles of objects can be described in relevant processes, which retain their association to facilitate downstream query answering or data validation. The pattern also removes the need for role-based relations such as {\ttfamily\bfseries hasPatient}, {\ttfamily\bfseries hasCareProvider}.


\subsection {Application of SULO}

\subsubsection{SULO with SNOMED CT}
The use of upper-level ontologies with domain terminologies such as SNOMED CT is increasingly recognized as essential for achieving semantic interoperability in healthcare and biomedical research. In \cite{schulz2015harmonizing}, an alignment of SNOMED CT with the upper-level ontology BioTopLite2 (BTL2) \cite{schulz2013biotoplite} was proposed and an alignment of SNOMED CT findings and disorders, as well as the SNOMED relations {\ttfamily\bfseries findingSite} and {\ttfamily\bfseries RoleGroup} were proposed in \cite{Schulz2023SnomedBFO}. Based on that, SNOMED CT upper-level classes and relations have been aligned with SULO. Table \ref{tab:snomed_sulo_combined} show the mapping of the main SNOMED CT classes and relations. It was done manually, by analysing the meaning of the candidate classes and relations, considering the formal axioms as well as text definitions and hierarchical context.

\begin{table}[h!]
\centering
\scriptsize
\caption{Mappings between SNOMED CT Top Concepts and Relations and corresponding SULO Classes and Properties}
\label{tab:snomed_sulo_combined}

\begin{tabular}{p{5cm}p{3cm}|p{4cm}p{3cm}}
\textbf{SNOMED CT Top Concept} & \textbf{SULO Class} & \textbf{SNOMED CT Relation} & \textbf{SULO Object Property} \\
\hline
Clinical finding (finding) & \multirow{3}{*}{sulo:Process} & Occurrence (attribute) & sulo:atTime \\
\cline{3-4}
Procedure (procedure) & & Finding site (attribute) & \multirow{2}{*}{sulo:isIn} \\
Action (qualifier value) & & Procedure site - Direct (attribute) & \\
\cline{1-2}
\cline{3-4}
Organism (organism) & \multirow{7}{*}{sulo:SpatialObject} & Using device (attribute) & \multirow{4}{*}{sulo:hasParticipant} \\
Specimen (specimen) & & Causative agent (attribute) & \\
Substance (substance) & & Due to (attribute) & \\
Pharmaceutical / biologic product (product) & & Procedure device (attribute) & \\
\cline{3-4}
Environment or geographical location (environment/location) & & Laterality (attribute) & \multirow{5}{*}{sulo:hasFeature} \\
Physical object (physical object) & & Associated morphology (attribute) & \\
Body structure (body structure) & & Has basic dose form (attribute) & \\
\cline{1-2}
Observable entity (observable entity) & \multirow{4}{*}{sulo:InformationObject} & Access (attribute) & \\
Record artifact (record artifact) & & Component (attribute) & \\
\cline{3-4}
Situation with explicit context (situation) & & Has active ingredient (attribute) & \multirow{4}{*}{sulo:hasPart} \\
Staging and scales (staging scale) & & Specimen substance (attribute) & \\
\cline{1-2}
Physical force (physical force) & sulo:Feature & Method (attribute) & \\
\cline{1-2}
Time (property) (qualifier value) & sulo:Time & Role Group (attribute) & \\
\cline{1-2}
Unit of measure (qualifier value) & sulo:Unit & & \\
\end{tabular}
\end{table}



SNOMED Ct is expressible in OWL-EL. Classes are defined using an {\ttfamily\bfseries is-a} hierarchy of primitives and attribute-value axioms, for which equivalence can be stated for new, fully defined classes. Attributes always correspond to OWL object properties and values to existentially qualified expressions. SNOMED CT class expressions may be formalised against SULO using SULO classes, relations, design patterns, and SULO-SNOMED mappings together. All SNOMED concepts with the label \textit{x} (disorder) have the implicit meaning that part of a patient's life include the disorder \textit{x} as per \cite{Schulz2023SnomedBFO}. Consider \textit{Fracture of femur (disorder)} shown for SNOMED in Figure \ref{lst:sct_femur}, and transformed to a SULO-based representation in Figure \ref{lst:sulo_femur}. A disorder in SNOMED CT is represented as a \textit{Process} in SULO which is located in a bone structure of femur that has the morphologic abnormality of being fractured.  

\begin{minipage}{\linewidth}
\begin{lstlisting}[language=ManchesterOWL2, label={lst:sct_femur}, caption={SNOMED class definition for Fracture of Femur (disorder)},  captionpos=b]
Class: 'Fracture of femur (disorder)'

  EquivalentTo: 
    'Disease (disorder)'
    and 'Role group (attribute)' some (
        'Associated morphology (attribute)' some 'Fracture (morphologic abnormality)'
        and
        'Finding site (attribute)' some 'Bone structure of femur (body structure)'
    )
\end{lstlisting}
\end{minipage}


\begin{minipage}{\linewidth}
\begin{lstlisting}[language=ManchesterOWL2, label={lst:sulo_femur}, caption={SULO representation of SNOMED Fracture of femur}, captionpos=b]
Class: 'Fracture of femur (disorder)'

    EquivalentTo:
    'Disease (disorder)'
        and sulo:hasPart some (
            (sulo:Process and sulo:isIn some
            'Bone structure of femur (body structure)'
                and sulo:hasFeature some 'Fracture (morphologic abnormality)')
        )
\end{lstlisting}
\end{minipage}


%%%%  work out the procedure example.
%%Class: 'Removal of stent (procedure)'

 %% EquivalentTo: 
 %%   'Procedure (procedure)'
  %%  and 'Role group (attribute)' some (
  %%      ('Method (attribute)' some 'Removal - action (qualifier value)')
    %%    and
      %%  ('Direct device (attribute)' some 'Stent (physical object)')
%%    )
%%\end{lstlisting}

 %%EquivalentTo: 
   %% 'Procedure (procedure)'
%%    and sulo:hasPart some (
%%        'Removal - action (qualifier value)'
%%        and
%%        sulo:hasParticipant (:DirectDeviceRole 
%%            and sulo:isFeatureOf 'Stent (physical object)')
%%    )

%%% discuss new role class for 'Direct device (attribute)' 

\subsubsection{SULO with SPHN}
The Swiss Personalized Health Network (SPHN) initiative developed an RDF schema to share health-related data between health data providers ~\cite{sphn_toure2023fairification}. While schema are valuable in constraining the shape and content of data, the SPHN schema suffers from several problems including: extensive use of non-reusable specialized predicates that necessitates class-specific lookups and incompatible changes in schema classes and relations across subsequent versions that add burden to implementers. We posit that adoption of SULO as a foundation ontology would increase ease of use.

Let us first consider the schema for the class \textit{Administrative Case} (see Table \ref{tab:sphn_ac_comparison}). \textit{AdministrativeCase} aims to capture a set of information relating to the admission, care and discharge of a patient during a contiguous patient encounter. The class includes relations such as {\ttfamily\bfseries hasAdmission} and {\ttfamily\bfseries hasIdentifier}, pointing to instances of the class \textit{Admission} and the datatype \textit{xsd:string}, respectively.  However, the SPHN schema for \textit{AdministrativeCase} has been revised over time, changing both the names of the relations as well as the set of classes. \textit{AdministrativeCase} in the 2023.2 version of SPHN was defined by a drastically different schema. In the 2023 version, the admission datetime and location, as well as the discharge location and datetime were specified as part of the \textit{AdministrativeCase}. The new version introduces two new classes, namely \textit{Admission} and \text{Discharge} (see Table \ref{tab:sphn_2025_admission_discharge}), are related by {\ttfamily\bfseries hasAdmission} and {\ttfamily\bfseries hasDischarge}, respectively. While both classes reuse a {\ttfamily\bfseries hasDatetime} relation to capture the time of the event, they use distinct relations ({\ttfamily\bfseries hasOriginLocation}, {\ttfamily\bfseries hasTargetLocation} to indicate a location. Confusingly, {\ttfamily\bfseries hasOriginLocation} specifies the physical location from where the individual came from (prior to admission), while {\ttfamily\bfseries hasTargetLocation} indicates the location that the individual supposed to go after discharge. While one might want to specify the actual location (e.g. departments in the care facility) of the admission or discharge, the schema lacks the capability to allow this.

%%%%

\begin{table}[h!]
\centering
\caption{Comparison of SPHN Administrative Case Schema (v.2023.2 vs v.2025.1)}
\label{tab:sphn_ac_comparison}
\begin{tabular}{c c | p{4.5cm} p{3cm} p{5cm}}
\textbf{2023.2} & \textbf{2025.1} & \textbf{Property} & \textbf{Cardinality} & \textbf{Range} \\
\hline
✓ & ✓ & hasIdentifier & 1..1 & xsd:string \\
✓ & ✓ & hasSubjectPseudoIdentifier & 1..1 & SubjectPseudoIdentifier \\
✓ & ✓ & hasCareHandling &  0..1 &  CareHandling \\
- & ✓ & hasAdmission & 1..1 & Admission  \\
✓ & - & hasAdmissionDatetime &  1..1 & xsd:dateTime \\
✓ & - & hasAdmissionLocation & 0..1 & Location \\
- & ✓ & hasDischarge & 0..1  & Discharge  \\
✓ & - & hasDischargeDatetime &  0..1 &  xsd:dateTime \\
✓ & - & hasDischargeLocation &  0..1 & Location \\
✓ & - & hasDataProviderInstitute & 1..1 & DataProviderInstitute \\
- & ✓ & hasSourceSystem & 1..* & SourceSystem  \\

\end{tabular}
\end{table}



\begin{table}[h!]
\centering
\caption{Schema definition for SPHN (v.2025.1) Admission and Discharge}
\label{tab:sphn_2025_admission_discharge}
\begin{tabular}{c c | p{3cm}p{3cm}p{2cm}p{4cm}}
\textbf{2023.2} & \textbf{2025.1} & \textbf{Class} & \textbf{Property} & \textbf{Cardinality} & \textbf{Range} \\
\hline
– & ✓ & \multirow{2}{*}{Admission} & hasOriginLocation & 0 .. 1 & Location \\
– & ✓ & & hasDatetime & 1 .. 1 & xsd:dateTime \\
\hline
– & ✓ & \multirow{2}{*}{Discharge} & hasTargetLocation & 0 .. 1 & Location \\
– & ✓ & & hasDatetime & 1 .. 1 & xsd:dateTime \\
\end{tabular}
\end{table}

\begin{lstlisting}[language=ManchesterOWL2, label={lst:sulo_ac}, caption={Class Expression for a SULO-compliant representation of SPHN class Administrative Case}, captionpos=b, float, floatplacement=ht]
Class: 'Administrative Case'

    subClassOf:
    sulo:Process
        and sulo:hasParticipant some (
            'Subject of Care Role'
                and sulo:isFeatureOf some (
                    Person
                    and sulo:hasFeature some (
                        SubjectPseudoIdentifier
                        and sulo:hasValue value xsd:string # subjectpseudoidentifier
                    )
                )
            )
        and sulo:hasPart some (
            PreAdmission 
            and sulo:isIn some SpatialObject # sourceLocation
        )
        and sulo:hasPart some (
            Admission
            and sulo:atTime some (
                TimeInstant
                and hasValue value xsd:dateTime # admission datetime
        )
        and sulo:hasPart some CareHandling
        and sulo:hasPart some (
            Discharge 
            and sulo:atTime some (
                TimeInstant
                and hasValue value xsd:dateTime # discharge datetime
        )
        and sulo:hasPart some (
            PostDischarge 
            and sulo:isIn some SpatialObject # targetLocation
        )
        and sulo:isReferredToIn some InformationObject # sourceSystem

\end{lstlisting}



The application of SULO and its ODPs can better inform schema development so as to maximize modularity, minimize complexity, and make enhance backwards compatibility of new schemas. Let us fully consider the \textit{AdministrativeCase} using SULO semantics, captured as a parameterized class expression in Figure \ref{lst:sulo_ac}, where the '?var' indicates the variable to be filled from query on the schema. {\ttfamily\bfseries hasSubjectPseudoIdentifier} specifies a pseudoanonimized patient identifier. In SULO, a patient pseudoidentifier is a kind of \textit{InformationObject}, which {\ttfamily\bfseries isFeatureOf} a person (a kind of \textit{SpatialObject}) that plays the \textit{SubjectOfCareRole} in an \textit{AdministrativeCase}. In the earlier formulation of SPHN, the properties of {\ttfamily\bfseries hasAdmissionDateTime} and {\ttfamily\bfseries hasDischargeDateTime} indicate the time instants at which the admission and discharge processes were recorded in the information system, rather than being an accurate description of either the start or end of those processes. If we assume that these time instants are contained within the actual admission and discharge processes, the SULO representation is that the administrative case has an admission process and a discharge process as its parts, and each part is associated with distinct time instants and values. However, given the semantics of {\ttfamily\bfseries hasOriginLocation} and {\ttfamily\bfseries hasTargetLocation}, we treat these as separate pre-admission and post-discharge processes that are located in the respective sites. While the schema for  \textit{AdministrativeCase} has undergone major changes, we can  faithfully represent the intended knowledge by reusing SULO relations and ODPs. 

\subsubsection{SULO vs BFO}

To validate SULO's alignment with established ULOs and ensure broader interoperability, we performed an explicit mapping to BFO 2.0. BFO is widely adopted in biomedical and scientific communities \cite{bfo}, offering a foundational framework for rigorous ontological modeling. We manually mapped the classes and relations between SULO and BFO through careful conceptual analysis, matching each SULO class and relation to the most semantically appropriate BFO counterpart (omitted owing to space constraints).
% Tables \ref{tab:sulo_bfo_classes} and \ref{tab:sulo_bfo_relations} present the detailed mappings for classes and relations, respectively. Several SULO classes serve as superclasses or subclasses of specific BFO classes, highlighting SULO's flexibility in encapsulating essential BFO concepts.

Some mappings revealed noteworthy differences. For instance, {\ttfamily\bfseries bfo:}{\ttfamily\bfseries existsAt} links an \textit{occurrent} to a \textit{temporal region} (which is also an occurrent), whereas {\ttfamily\bfseries sulo:}{\ttfamily\bfseries atTime} relates any entity, including \textit{continuants}, to {\ttfamily\bfseries sulo:}{\ttfamily\bfseries Time}, which is modeled as a \textit{generically dependent continuant}. This demonstrates an difference in the treatment of temporal concepts. Additionally, BFO (v1/v2) does not explicitly support linking information artifacts to universals. In contrast, the Information Artifact Ontology (IAO), which many BFO-based ontologies adopt, permits {\ttfamily\bfseries iao:}{\ttfamily\bfseries isAbout} to refer to both individuals and classes. SULO's {\ttfamily\bfseries hasFeature} relation, intended as a structural link between an entity and its features (e.g., quality, role), is loosely aligned with {\ttfamily\bfseries iao:}{\ttfamily\bfseries isAbout}. However, {\ttfamily\bfseries iao:}{\ttfamily\bfseries isAbout} implies an epistemic or representational relationship, leading to a semantic mismatch. This distinction underscores a broader challenge in harmonizing ontological and epistemological roles of predicates.
Finally, SULO features may be features of everything, while BFO dependent continuants exclude processes. Thus, BFO precludes the definition of qualities of processes. BFO:Quality is therefore strictly limited to non-processes, whereas SULO does not impose any restriction. This mapping exercise demonstrates SULO's capability to function as an intermediary layer, preserving compatibility with BFO-based ontologies while simplifying conceptual complexity. 


% \subsubsection{SULO vs BioTop}
% BioTop in its lite version (BTL2) \cite{schulz2013biotoplite} has 54 classes, 37 object properties and one data property. In the following we show the mapping between main BTL2 classes and properties with SULO. The mapping was done manually by analysing the formal definitions and descriptions. Tables \ref{tab:biotop_sulo_mapping_class} and \ref{tab:biotop_sulo_mapping_relations} show some of the mappings.

%% maybe comment on btl2:hasRealization representation using sulo:isFeatureOf
%%That in BTL2 we have btl2:projectsOnto with range a value temporal region, whereas in sulo, sulo:atTime and that the btl2:isBearerOf which holds for process and material object here is sulo:hasFeature. As in SULO there is just one datatype property btl2:hasValue

%%In BTL2 we have quality, disposition and role as separated classes, as well as classes for process quality and object quality as subclasses of btl2:Quality. btl2:InformationObject is also a separated class and is disjoint with quality, disposition and role.

\subsubsection{SULO vs SIO}
SULO and SIO share a very high degree of similarity in the set of classes and relations as well as the taxonomic organisation of the ontology. The \textit{core} \footnote{\url{http://semanticscience.org/ontology/sio/v1.59/sio-subset-core.owl}} version of SIO comprises 15 classes, 34 object properties, and one data property. SULO and SIO (core) share a large set of common classes including \textit{Process}, \textit{Object}, \textit{Feature} maps to SIO's \textit{attribute}, \textit{Quality}, \textit{Capability}, \textit{Role}, \textit{InformationObject} maps to SIO's \textit{information content entity}, \textit{SpatialObject} maps to SIO's \textit{material entity}. The top level of the ontologies is structured differently. \textit{entity} is at the root of the SIO ontology, which then specialises into three subclasses \textit{process}, \textit{object}, and \textit{attribute}. In contrast, SULO's \textit{Process} and \textit{Object} classes are at the top, and its \textit{Feature} class is a subclass of \textit{Object}. As such, the ontological commitment is that dependent entities (attributes in SIO) are disjoint from objects and processes, and this is incompatible with SULO's representation where dependent entities (features in SULO) are types of objects. Therefore, while the is a correspondance between classes, a strict mapping between these ontologies would yield an inconsistent ontology. SULO and SIO share set of core object properties including {\ttfamily\bfseries hasParticipant}, {\ttfamily\bfseries isPartOf}, {\ttfamily\bfseries refersTo}, {\ttfamily\bfseries precedes}, {\ttfamily\bfseries isIn}, whereas {\ttfamily\bfseries atTime} maps to SIO's {\ttfamily\bfseries exists at}, {\ttfamily\bfseries hasFeature} maps to {\ttfamily\bfseries has attribute}, and {\ttfamily\bfseries hasItem} maps to {\ttfamily\bfseries has data item}. However SIO has a more expansive set of relations that are role specializations that SULO rejects (e.g. {\ttfamily\bfseries has input}, {\ttfamily\bfseries has output}, {\ttfamily\bfseries has agent}) as well as spatial, temporal and information-based relations that provide additional expressivity in the formalisation of domains (e.g. {\ttfamily\bfseries realizes}, {\ttfamily\bfseries is variant of}, {\ttfamily\bfseries is connected to}, {\ttfamily\bfseries in relation to}. Finally, both ontologies share the {\ttfamily\bfseries hasValue} data property, and support the modeling advocated by the SOLID design pattern. 

    
\section{Discussion}
SULO takes a minimalistic approach to guide the alignment, formalisation, and reusability of upper-level and domain ontologies, aiming to balance formal rigour with simplicity and practical usability. SULO's core principles are central to its design and intended impact:

\textbf{Minimalism}: SULO proposes a small taxonomy of 17 disjoint classes, a minimal set of 18 object properties (9 direct + 9 inverse), and 1 data property to ensure broad applicability across domains. This minimal set covers the representational needs in the biomedical use cases examined.

\textbf{Compatibility}: SULO aims to maintain compatibility with core components of well-known ULOs (e.g., BFO, SIO, UFO, GFO, DOLCE, YAMATO, BioTop) while remaining accessible to domain experts. Owing to its minimalist approach, SULO serves as a compatibility layer between ULOs by focusing on key aspects of ontology, for which more specialised theories may be found in other ULOs.

\textbf{Accessibility}: SULO strives to be accessible to users with little or no training in formal ontology through friendly labeling, a simple taxonomy, and a general overview that fits in a single diagram. This approach aims to provide a low-threshold entry into principled domain modeling, avoiding the ontological and logical intricacies of more fine-grained ULOs. The widely adopted Ontology Development 101 guide \cite{noy2001ontology} with the well-known Pizza and Wine ontologies has shaped ontology education over decades based on frame-based modeling, which neglected key concerns central to applied ontology, \textit{viz.} ontological clarity, interoperability, and alignment with upper-level ontologies \cite{schulz_pizza_2017}. Future ontology education must move beyond illustrative examples and tool-centric instruction, towards ontological rigor, modularity, and principled alignment with SULO. 

\textbf{Composability}: SULO offers a set of building blocks, namely classes and object and data properties, with which more complex class expressions can be formulated. In particular, we show how select complex class expressions in SNOMED CT can be rewritten as SULO expressions without introducing additional relations. Similarly, SULO is sufficiently expressive to capture the semantics of different version of the SPHN schema. SULO is available as an OWL-DL ontology, which is amenable to automated reasoning in order to check the satisfiability of expert-composed class expressions.

\textbf{Interoperability}: SULO's effectiveness as a interoperability hub is significantly enhanced the adoption of ontology design patterns (ODPs). We introduces two such patterns - SOLID and PRO - which aim to reduce the proliferation of domain-specific role-based relations. The ODPs are simultaneously useful to map relations found in the SNOMED ontology and the SPHN schema to SULO-compatible representations. However, the adoption of such patterns may require the introduction of new classes that currently don't exist. The formalisation of additional ontology design patterns \cite{Gangemi2009} grounded to SULO may improve their uptake in biomedical ontologies \cite{Ochs2017}. Our analysis of the SPHN schema illustrates how such schemas can be formulated without referring to specific domain relations, and that adopting a set of common design patterns maximizes modularity and enhances backwards compatibility.

\textbf{Application-Driven Validation}: Data validation is a key part of modern information systems. However, many schemas are constructed without considering the semantic foundation that ontologies provide. This yields schemas that closely mirror their data, and are otherwise difficult to reuse or extend for similar dataset. While much if not all of SPHN can be mapped to SULO, it remains future work to show how a SULO-based SPHN schema could bring significant benefits to the construction and maintenance of evolving schemas for data-validation. 

% %% simplification from other ULOs; comparison of BFO, DOLCE, BioTop, SIO
% % foundationless ontologies

\section{Conclusion and Future Work}
SULO was developed to address the significant challenges of ontology-based data integration in healthcare and life sciences, where the complexity of existing upper-level ontologies (ULOs) often limits the extent and correctness of adoption by domain experts and standards developers. Despite the recognised need for interoperable representations, many domain ontologies and schemas are created without reference to a foundation ontology. SULO takes a minimalistic approach that balances formal rigour with simplicity and practical usability. Future work will explore more complete mappings to well known ULOs and to apply SULO to a broader set of use cases in biomedicine and healthcare, as well as to other disciplines to uncover limitations and potential opportunities for further refinement.

\section*{Declaration on Generative AI}
During the preparation of this work, the author(s) used GPT-4 to help with LaTeX styling. The authors reviewed and edited the content as needed and take full responsibility for the publication's content. 
 
\section*{Acknowledgments}
This work is supported by the Horizon Europe Framework Program under Grant Agreement Nos. 101057062 (AIDAVA), 101112022 (iCare4CVD), 101095435 (REALM), 101057603 (RES-Q+), 101080875 (CMC), and the Spanish Research Agency Grant RYC2020-030190-I.

\bibliography{main.bib}

\end{document}