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 ofer 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.
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 what
exists. Examples are BFO [
ULOs are grounded in diferent metaphysical commitments and modeling styles. They are motivated
by diferent 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 what exists in a specific domain, by ofering
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 [
Apart from terminologies and ontologies, many domain schemas have also been developed. Even
sometimes called “ontologies” or “schemas” (such as the SPHN [
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 upperlevel ontologies, domain-specific upper ontologies, legacy terminology frameworks, or domain-specific schemas. Such decisions have to take into consideration: • 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 [ 15]. ULOs adopting particular philosophical stances such as realism facilitate some domain applications, while struggling with others [16][17] • 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 ofer any data properties to capture literal values, e.g. numeric values characterizing measurements. • The foundational categories of ULOs and the top level of domain ontologies often use labels that carry implicit assumptions, e.g. Object, Process, Event, Function, Quality, and Disposition. These assumptions difer 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 [15]. This is particularly true with systems that carry a strong legacy, such as SNOMED CT [11] with upper-level categories labeled such as Clinical Finding, Observable, Qualifier Value. They lack clear definitions, are dificult to translate and therefore dificult to map to ULOs[18]. • Some ULOs deliberately adopt unfamiliar or technical labels derived from philosophical ontology such as Continuant, Endurant, Perdurant, 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 difrently in deferent disciplines. • Domain ontologies often show an excess of diferent 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 “hasRangeType”, such as hasPatient, ifndingSite, hasTemperature where the range is implicitly constrained by the target class.
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 [19]. Towards addressing the aforementioned issues, we propose SULO (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: • Minimalism: SULO proposes a small taxonomy of disjoint classes and a minimal set of constrained relations to ensure broad applicability across domains. • 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 between established ULOs. • 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. • Composability: SULO will provide the building blocks to construct complex, machine-readable class expressions. • 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. • Data validation: SULO constrains real-world knowledge graphs through automated reasoning and schema validation.
These principles support a flexible framework for aligning and integrating biomedical data representations and standards, by ofering 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 more fine-grained and expressive ULOs.
We followed the NEON methodology [20], 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 [21], which targets the rendering of healthcare processes as knowledge graphs rooted in
semantic standards, and which currently uses the SPHN schema[
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 1, and are further described in this section.
SULO comprises seven taxonomic levels, which are mutually disjoint at each level (see Figure 2).
A Process has temporal parts, unfolds in time, has a duration and has objects as participants (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.
An Object maintains its identity through time, does not have processes as its parts, but participates in processes. Objects are dichotomized into SpatialObject (e.g. a person, a particle, a paper document, a hospital) and Feature. A 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 Feature is an object that existentially depends on other things, whether objects or processes. The class Feature includes Quality (e.g. the redness of an apple), Role (e.g. the role of a care subject, a care provider, a student or a blood donor), Capability (e.g. the capability to breathe or to produce ofspring), as well as InformationObject (e.g. the content of a document, a clinical practice guideline, a mathematical formula).
An InformationObject is a Feature whose existence depends on and is about something. Two subclasses of InformationObject are introduced, viz. Collection and Quantity. A Collection is an InformationObject pertaining to classes and mathematical sets, while a Quantity is an InformationObject that captures a numerical aspect (of an attribute) with a value and optional Unit, and is further divided into two 1https://github.com/AIDAVA-DEV/sulo; with the namespace https://w3id.org/sulo/ and an OWL/Turtle representation at https://w3id.org/sulo/sulo.ttl
subclasses Time and Unit. In SULO, Time is a Quantity - it is a measurement of time (it does not ofer an ontology of time). SULO’s Time class is divided into 3 subtypes: a TimeInstant, TimeInterval, and Duration of time. StartTime and EndTime are role-playing TimeInstant that are useful in demarcating the boundaries of a Process or TimeInterval.
SULO ofers 18 object properties (9 direct + 9 inverses) and one data property.
owl:TopObjectProperty owl:TopDataProperty atTime precedes hasParticipant hasFeature refersTo hasMember hasValue isIn isPartOf isDirectPartOf 4.3.1. 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. isIn (inverse: contains) is a transitive binary relation where the object includes the subject within its spatial, temporal, structural, or conceptual extent. The atTime (inverse: isTimeOf) relation holds between any entity and a time measurement. It captures the notion of when in time something exists or occurs. The 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. 4.3.2. Parthood The isPartOf (inverse: hasPart) relation is a transitive and 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 isPartOf y during some Time t. Examples include myLeftVentricle isPartOf myHeart, this administration of ibuprofen isPartOf treatment of my headache, this premise isPartOf that argument. The isDirectPartOf (inverse: hasDirectPart) relation is a non-transitive subrelation of 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. hasDirectPart is the inverse relation of isDirectPartOf. An example class expression is Human Heart subClassOf SpatialObject that hasDirectPart exactly 2 Ventricle. 4.3.3. Descriptors The hasFeature (inverse: isFeatureOf) relation holds between any entity and a Feature. For instance, a three-dimensional SpatialObject is associated with the Quality of Volume, which may be measured and reported as a Quantity atTime Time. 4.3.4. Participation in Processes The hasParticipant (inverse: isParticipantIn) relation holds between a Process and an Object. We capture the notion that when a Feature participates in a Process, then so does the Object for which it is a Feature of through the role chain hasParticipant o isFeatureOf → hasParticipant. A key design pattern is to represent the diferent roles that objects play in a particular process. For instance, the Process of Administration of Medication might involve one individual playing a Care Provider Role, which administers the medication to another individual playing a Care Subject Role. 4.3.5. Relations for information objects An InformationObject always refersTo (inverse: isReferredToIn) some other thing it mentions, describes, represents or otherwise is information about. The hasValue relation is a functional data property to capture a single literal associated with an InformationObject. No other data property is admitted. The hasItem (inverse: isItemIn) relation holds between a Collection and the items that constitute this collection. Finally, the physical representation of an InformationObject to a SpatialObject can be indicated with the isFeatureOf relation.
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 “hasRangeType”, such as hasPatient, findingSite, 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 diferent 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. 4.4.1. SOLID (Single Object Literal Information Datum) Design Pattern The SOLID pattern uses SULO’s single functional datatype property, hasValue, to assign a literal value to an instance of an InformationObject. This pattern transforms the introduction of domain-specific data properties such as hasTemperature by first extracting the implied classes (e.g., Temperature) that pertain to a relevant 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 4). Instead of using arbitrary relations such as hasTemperature or hasTemperatureInCelcius, the design pattern reuses SULO’s hasValue data property, hasFeature, refersTo and hasPart object properties in conjunction with two externally defined classes, namely Temperature from PATO and 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 hasValue data property. :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 4.4.2. 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[ 24] class expression in Figure 5 requires that particular roles are directly linked to a process instance using hasParticipant and to their respective role holders using isFeatureOf: EquivalentTo:
Process and hasParticipant some (
Role and isFeatureOF some Object )
We recover the participation of the role holder by inference through a role chain (Figure 6): hasParticipant o isFeatureOf -> hasParticipant
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 7). Applying the PRO pattern, the health care encounter (encounter is a Process) in which the two instances of roles (alice_subject_of_care_role, smith_physician_role) instantiating ’patient role’ and ’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, encounter has alice and drsmith as participants. @prefix sulo: <http://w3id.org/sulo/> . @prefix obo: <http://purl.obolibrary.org/obo/> :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 obo:OMRSE_00000011; # patient role
sulo:isFeatureOf :alice . :smith_care_provider_role a obo:OMRSE_00000012; # health care provider role
sulo:isFeatureOf :drsmith . :alice a sulo:SpatialObject, taxon:NCBITaxon_9606 . # human :drsmith a sulo:SpatialObject, taxon:NCBITaxon_9606 . # human ### inference from PRO role chain :visit_1 sulo:hasParticipant :alice, :drsmith . 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 hasPatient, hasCareProvider.
4.5.1. 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 [25], an alignment of SNOMED CT with the upper-level ontology BioTopLite2 (BTL2) [26] was proposed and an alignment of SNOMED CT findings and disorders, as well as the SNOMED relations findingSite and RoleGroup were proposed in [18]. Based on that, SNOMED CT upper-level classes and relations have been aligned with SULO. Table 1 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. 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 x (disorder) have the implicit meaning that part of a patient’s life include the disorder x as per [18]. Consider Fracture of femur (disorder) shown for SNOMED in Figure 8, and transformed to a SULO-based representation in Figure 9. A disorder in SNOMED CT is represented as a Process in SULO which is located in a bone structure of femur that has the morphologic abnormality of being fractured.
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)’
)
4.5.2. SULO with SPHN
The Swiss Personalized Health Network (SPHN) initiative developed an RDF schema to share
healthrelated data between health data providers [
Let us first consider the schema for the class Administrative Case (see Table 2). 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 hasAdmission and hasIdentifier, pointing to instances of the class Admission and the datatype xsd:string, respectively. However, the SPHN schema for AdministrativeCase has been revised over time, changing both the names of the relations as well as the set of classes. AdministrativeCase in the 2023.2 version of SPHN was defined by a drastically diferent schema. In the 2023 version, the admission datetime and location, as well as the discharge location and datetime were specified as part of the AdministrativeCase. The new version introduces two new classes, namely Admission and Discharge (see Table 3), are related by hasAdmission and hasDischarge, respectively. While both classes reuse a hasDatetime relation to capture the time of the event, they use distinct relations (hasOriginLocation, hasTargetLocation to indicate a location. Confusingly, hasOriginLocation specifies the physical location from where the individual came from (prior to admission), while 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.
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 AdministrativeCase using SULO semantics, captured as a parameterized class expression in Figure 10, where the ’?var’ indicates the variable to be filled from query on the schema. Range xsd:string
xsd:dateTime
xsd:dateTime
hasSubjectPseudoIdentifier specifies a pseudoanonimized patient identifier. In SULO, a patient
pseudoidentifier is a kind of InformationObject, which isFeatureOf a person (a kind of SpatialObject)
that plays the SubjectOfCareRole in an AdministrativeCase. In the earlier formulation of SPHN, the
properties of hasAdmissionDateTime and 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
hasOriginLocation and hasTargetLocation, we treat these as separate pre-admission and
postdischarge processes that are located in the respective sites. While the schema for AdministrativeCase
has undergone major changes, we can faithfully represent the intended knowledge by reusing SULO
relations and ODPs.
4.5.3. 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 [
Some mappings revealed noteworthy diferences. For instance, bfo:existsAt links an occurrent to a temporal region (which is also an occurrent), whereas sulo:atTime relates any entity, including continuants, to sulo:Time, which is modeled as a generically dependent continuant. This demonstrates an diference 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 iao:isAbout to refer to both individuals and classes. SULO’s hasFeature relation, intended as a structural link between an entity and its features (e.g., quality, role), is loosely aligned with iao:isAbout. However, iao:isAbout implies an epistemic or representational relationship, leading to a semantic mismatch. This distinction underscores 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 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 nonprocesses, 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. 4.5.4. 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 core 2 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 Process, Object, Feature maps to SIO’s attribute, Quality, Capability, Role, InformationObject maps to SIO’s information content entity, SpatialObject maps to SIO’s material entity. The top level of the ontologies is structured diferently. entity is at the root of the SIO ontology, which then specialises into three subclasses process, object, and attribute. In contrast, SULO’s Process and Object classes are at the top, and its Feature class is a subclass of 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 hasParticipant, isPartOf, 2http://semanticscience.org/ontology/sio/v1.59/sio-subset-core.owl refersTo, precedes, isIn, whereas atTime maps to SIO’s exists at, hasFeature maps to has attribute, and hasMember maps to has data item. However SIO has a more expansive set of relations that are role specializations that SULO rejects (e.g. has input, has output, has agent) as well as spatial, temporal and information-based relations that provide additional expressivity in the formalisation of domains (e.g. realizes, is variant of, is connected to, in relation to. Finally, both ontologies share the hasValue data property, and support the modeling advocated by the SOLID design pattern.
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:
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.
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.
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 [27] 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, viz. ontological clarity, interoperability, and alignment with upper-level ontologies [28]. Future ontology education must move beyond illustrative examples and tool-centric instruction, towards ontological rigor, modularity, and principled alignment with SULO.
Composability: SULO ofers 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 suficiently expressive to capture the semantics of diferent 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.
Interoperability: SULO’s efectiveness 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 [29] grounded to SULO may improve their uptake in biomedical ontologies [30]. 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.
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 dificult 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.
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.
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.
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.