The Brainteaser Ontology

3 Co-Design Approach

To design the BO ontology we adopted a co-design approach, strictly collaborating with the medical partners and domain experts, in order to embed their knowledge in the BO and, at the same time, to validate all the design choices. To this end, we operated in an iterative way, producing several intermediate versions of the ontology and discussing them with our domain experts.

The design of the BO started by discussing with all the partners which kind of data have to be managed via the ontology and this ended-up on identifying the three categories mentioned above in Section 1: “raw” data, generated data, and evaluation campaigns data. The discussion was initiated during the kickoff meeting in January 2021 and finalized in the first plenary meeting in April 2021.

At this point, the work specifically focusing on retrospective data started. The UNIPD team received simplified samples of data from the medical partners in order to start understanding their features and potential issues. We then prepared forms to elicit requirements from the medical partners and collect attributes that they deemed important to describe both ALS and MS.

The requirement gathering and analysis phase ended up with a preliminary draft of the core parts of the BO and the corresponding schema. This preliminary draft of the BO was discussed face-to-face (virtually) in a dedicated meeting with medical partners in late May 2021, where we went through the overall design choices and the specific classes constituting the BO to validate them. The further feedback gathered from the domain experts led to a revision of the BO which was further discussed in another face-to-face virtual meeting in late June 2021. This additional feedback led to a further refinement of the BO which was then presented and agreed on during the overall plenary meeting in September 2021.

Just after the plenary meeting, full (and anonymized) retrospective data were received from the medical partners: Pavia for MS; Lisbon, Turin and Madrid for ALS. The inspection of the full raw data allowed to further improve and refine the ontology and also to discover some issues about the instances, related to incomplete or noisy data. These updates to the BO and the solutions to address specific issues have been then discussed in one-to-one meetings with the specific medical partner during October and November 2021.

Overall, all these iterations led to the development of the first version of the BRAINTEASER ontology as well as of the mappers for ingesting the retrospective data from the medical partners.

4. DESCRIPTION OF THE BRAINTEASER ONTOLOGY

In the following, we describe more in detail the ontology designed to model the Multiple Sclerosis and the Lateral Amyotrophic Sclerosis according to the co-design approach defined in Section 3. In this section we present the main components and the choices that we made, whereas the complete documentation will be uploaded with the final OWL file in an open public repository as Zenodo which enables the seamless integration with EOSC services. Subsection 4.1 details the principles that guided the development of the ontology, while Subsection 4.2 describes the main semantic areas and the principal classes available in each of them.

4.1 Overall design principles

The ontological modeling proceeded bottom-up starting from the anonymized clinical reports about the four considered diseases provided by the "Instituto de medicina molecular Joao Lobo Antunes" (iMM, Portugal) and Università degli Studi di Torino (UNITO, Italy) for ALS, and by Fondazione Istituto Neurologico Nazionale Casimiro Mondino (MNDV-PV, Italy) for MS.

We analyzed these records and worked together with the physicians and the expert researcher in the field, following shared co-design principles, to accurately identify the classes and relations to include in the ontology. We maximized the re-use of concepts defined in already available and well-known ontologies and vocabularies, thus limiting the creation of new classes and relations to a minimum.

We represent the ontology as a graph where nodes are classes and edges are typed relationships amongst the classes. Classes (nodes) represent real-world objects such as a person, a project, a tissue or an anatomical part.

Relationships (edges) describe how the classes interact one with each other. BO is composed of 362 classes, 360 named individuals, 76 object properties, 220 data properties, and EEE annotation properties. The prefixes used in the ontologies are reported in the table above. Amongst the most used external ontologies, we count the COMPLETE with statistics.

Once released, the URLs of the ontology will be secure and permanent by using the re-direction service provided by the W3 Permanent Identifier Community Group. The service works as a switchboard connecting requests for information with the true location of the information on the Web. It can be, therefore, reconfigured to point to a new location if the old location stops working.

4.1 Overall design principles

The ontology is divided into eight "semantic areas", i.e., groups of entities and relationships that pertain to different types of concepts and aspects of our domain. Each entity is therefore classified in one of the eight semantic areas. These areas are better detailed in section 4.2, and are:

1. Patient the semantic area describing aspects of the patient, such as their status, their relatives, the corresponding disease, and clinical trials to which they are participating.
2. Genetic Data the information about the genetic mutations of a patient.
3. Behavior containing entities about the behaviour kept by the patient through time, such as smoking, physical activity, and more generic lifestyle aspects.
4. Events classes describing the possible events being registered for a patient, such as diagnosis, onset, and interventions of different nature.
5. Contingencies an area containing classes describing things that can happen to the patient during their life, such as comorbidities and traumas of different kinds.
6. Intervention and Procedure containing classes about different types of procedures that the patient may incur during their clinical history. This is one of the largest areas of the ontology, and we divided it into sub-areas to better describe them depending on the nature of the procedure.
7. Anatomical Structure composed of subclasses describing different parts of the human body.
8. Symptoms subclasses describing symptoms of different nature that may happen to the patients.

4.1.2 External Ontologies and Taxonomies

Whenever possible, we re-used classes from other ontologies to represent entities and created new classes only when unavoidable. The external ontologies used for this are described in Section 2.4.

In particular, there are some cases where we imported a subset of entities from an external ontology in order to represent taxonomies of concepts and their rdfs:subClassOf relationships. We only imported from these taxonomies the classes that are useful to model the data necessary for the project, i.e. we never import the full taxonomies, but only subsets of them. Some of the classes that work as roots of their respective taxonomies in the Brainteaser ontology are:

1. Relative (ncit:C21480) This class represents a generic relative of a patient, and is the root of the taxonomy containing different degrees of kinship (such as Father, Mather, Sister, etc.)
2. Occupation (esco:Occupation) The class representing a generic job or other type of occupation of the patient.
3. Ethnic group (SNOMED:Ethnic_group) Represents the ethnicity of the patient.
4. Symptom (ncit:C4876) The root class of the taxonomy describing the possible symptoms related to a patient.
5. Gene (ogg:0000000002) Root of the gene taxonomy.
6. Anatomical Structure (uberon:0000061) Root of the taxonomy of the human body locations where events, symptoms and traumas are located.
7. Pharmacologic Substance (ncit:C1909) the root of the clinical drugs that may be prescribed to patients as result of a Therapeutic Procedure or as response to a Relapse or Inflammation.
8. Disease or Disorder (ncit:C2991) the root of the taxonomy with the possible diseases (not only MS and ALS) that a patient, or one of their relatives, may manyfest.

We relate each single concept in the BO with the respective concepts in the Unified Medical Language System (UMLS) metathesaurus with the oboInOwl:equivalentClass relationship. This connection allows us to retrieve all relevant information about a concept as reported in the rich and widely-used UMLS meta-thesaurus. UMLS comprehends alternative naming for the concepts, relationships with other relevant classification schemes such as the International Statistical Classification of Diseases and Related Health Problems, Tenth Revision (ICD-10) and multilingual information when available.

As an example, the "multiple sclerosis" concept is inherited from the MONDO ontology with URI http://purl.obolibrary.org/obo/MONDO_0005301 and in the BO definition for this concept we also report that it is the same as umls:C0026769. From the UMLS identifier we can retrieve all the information about other classifications such as ICD-10 that identifies multiple sclerosis with the id G35.

4.1.3 Named Individuals

For the classes contained in some of these taxonomies, i.e., the ones with root in Occupation, Ethnic Group, Anatomical Structure, and Pharmacological Substance, it is the case that, when they are the range of properties, no other information needs to be registered. For instance, when registering the presence of a symptom in a particular anatomical location, it is only necessary to know the location, without any further information about it.

The consequence is that each time a new triple with an object in one of these taxonomies is created, we would be forced to create a new instance.

To avoid an explosion in the number of instances of these classes, and due to the fact that no other information about them needs to be modeled, we decided to create named individuals, one for each class in these taxonomies. These named individuals are used as objects of the corresponding object properties every time a new triple needs to be instantiated.

4.2 Area-by-Area

In the remainder of this section, we describe the elements characterizing each semantic area individuated in section 4.1. We use the bold font to indicate ontological classes, monospace font to represent their URI and italic to represent their properties. In case of uri derived from other ontologies, prefixes are defined in Table 1.

4.2.1 Patient

The patient semantic area, represented in Figure 3, contains classes and relations pertaining to a patient participating in the clinical trials and general information about this patient, their relatives with diseases, their disease and the participation in a clinical trial.

Central to this area is the Patient class (ncit:C16960), subclass of foaf:Person, that presents different properties describing the Patient instance. These are: dateOfDeath (with range xsd:gYear), genomeSequencing (xsd:string), educationLevel (rdf:langString), maritalStatus (rdf:langString), dextricity (xsd:string), retiredAtDiagnosis (xsd:string), menopause (xsd:int), MSInPaediatricAge (xsd:boolean), alive (xsd:boolean).

Patient inherits from foaf:Person the properties birthplaceCharacteristics (rural or urban areas), and birthplace (defined as an enumeration among village, country town, small town, middle torn, and large town). The Patient is further linked to two additional attributes, gender through the foaf:gender property, and birthday, via foaf:birthday property. In order to preserve the anonymity of the patients, real instances will only present the birth year, and not the birth date.

Patient is connected through the ethnicity property to class Ethnic Group (SNOMEDCT:Ethnic_Group), representing a generic ethnic group. This class is the root of a taxonomy of ethnicities whose classes are taken from other ontologies.

To model the familial predisposition, it is necessary to register the presence of a patient's relatives that may have the studied diseases of their own. To do so, we considered the class Relative (ncit:C21480) that models a generic relative of a patient. Relative, in turn, is the root class of a taxonomy of kingship classifications such as Parent, FirstDegreeRelative, Father and Mother (these classes are imported directly from the ncit ontology).

A relative may or may not be a patient in the database. In the first case, the relative instance is connected to its corresponding patient instance through the isPerson property. In the other case, an instance of the class foaf:Person is created, and the relative instance is connected through isPerson to this instance. One patient or one generic person can be a relative of more than one patient, and for this reason multiple instances of relative may be instantiated, one for each degree of kinship occurring for that patient/person in the database. Each of these instances will be connected through isPerson to the corresponding instance of Patient or foaf:Person.

The class Occupation (ESCO:Occupation) represents the job of the user. It is the root class of a taxonomy of classes representing different types of jobs, and a patient instance is connected to Occupation through hasOccupation.

foaf:Person is connected through the property enrolledIn to Clinical Trial Participation (:ClinicalTrialParticipation), representing the fact that a patient is participating in a clinical trial. A clinical trial instance may have a startDate property, an endDate property and an ending reason, provided by the endReason property.

Each instance of clinical trial participation is part of a Clinical Trial (ncit:C71104) and connected to this class through the participate property. In turn, a clinical trial pertains to a certain hospital, and therefore the property connects the class Clinical Trial to the class Clinics and Hospitals (ncit:C19326).

Finally, a person (thus both a patient and a relative who is not present in a trial) can have a disease. foaf:Person is connected to Disease or Disorder (ncit:C2991) through hasDisease. Also, the class Clinical Trial is connected to Disease or Disorder through isAboutDisease to indicate which is the disease studied in the specific trial.

4.2.2 Genetic Data

A Patient may be associated with data concerning their genetic heritage. To do so, the ontology links the Patient, via the property hasGene, to the class Gene (ogg:0000000002), as shown in Figure 4. Instances of this class can have two properties: kind and open box. The former allows to express the type of mutation present on the gene, while the latter allows to add further information via unstructured text. The Gene instance can be instantiated either using the Gene class, or one of its relevant subclasses for this specific domain: SOD1 (ogg:3000006647), FUS (ogg:3000002521), C9orf72 (ogg:3000203228), and tardbp (ogg:3000023435).

4.2.3 Behaviour

Different aspects of the behaviour of the patient during the passing of time are modeled with classes in this semantic area.

As reported in Figure 5, the main class is Behaviour (ncit:C19683), presenting the properties startYear and endYear (both with range xsd:gYear), describing the starting and ending dates of said behaviour. Each instance of the subclasses of Behaviour therefore offers the possibility to register the time span in which such behaviour was sustained. The class Event is connected to Behaviour through hasRegisteredBehaviour.

Different types of behaviours are modeled through the use of subclasses of this main class.

Smoking (ncit:C154329) represents the patient's habit of smoking. It presents the relations packYear (a quantification of lifetime tobacco exposure defined as: (number of cigarettes smoked per day) x (number of years smoked)/20. Thus, one pack-year corresponds to smoking 20 cigarettes a day for one year), and dailyCigarettes (the number of cigarettes smoked in one day on average).

The class Physical Activity (ncit:C17708) describes the physical activity usually exerted by the patient. Its properties are intensity (xsd:string), weeklyFrequence (xsd:integer) and activityType (xsd:string).

The class Lifestyle (ncit:C16795) acts as a container where to put different types of behavioral information concerning the patient. Such behaviors are modeled as properties of the Lifestyle instance, and are: sunExposure (with range xsd:int), diet (xsd:int), fatigue (xsd:int), sexuality (rdf:langString), femalePeriodStartDate (xsd:date), and menopause (xsd:boolean).

4.2.4 Events

This Events semantic area, depicted in Figure 6, contains some of the most important classes of the ontology, as one of the goals of the ontology itself is to model the events pertaining to the patient and their evolution through time.

Main class here is Event (ncit:C25499), describing a generic event that can happen to a patient in a medical environment. The Event class is characterized by the two data properties endDate and startDate (both with range xsd:date), describing the period in which this Event manifested.

Different types of Event are represented through the use of subclasses.

Protocol Event (ncit:C74589) represents a planned protocol activity such as randomization and study completion, and occurrences, conditions, or incidents independent of planned study evaluations occurring during the trial (e.g., adverse events) or prior to the trial (e.g., medical history). Its subclass is Patient Visit (ncit:C39564), describing a specific type of protocol event, i.e., a visit of the patient in a hospital.

The event Diagnosis (ncit:C25279) represents the moment in which the patient is officially diagnosed with the disease.

The last two types of Event are the Onset (ncit:C25279) and Before Onset (:BeforeOnset). The first one represents the event in which the first symptoms are manifested for the first time to the patient. The Onset, in particular, may be of different types, which are represented as boolean (xsd:boolean) properties: limbs, bulbar, axial, and generalized. An onset may also present the property cerebrospinalOligloconalBands, which indicates, if the test has been carried out, the presence of such bands in the patient's blood flow. The onset is located in a part of the human body, and thus the Onset event is connected to the class Anatomical Structure (uberon:0000061) through the site property. The second one, Before Onset, describes an event that happened before the onset, whatever its nature may be. The property howLong registers how much time before the onset this event happened, and it may assume only two string values, defining an event that happened in the last five years, or before the last five years.

An Event instance, in turn, may be linked to various other classes. Event is linked through hasPregnancy to Pregnancy, describing the presence of a pregnancy; to Trauma through hasTrauma, describing the registration of a traumatic event happened to the patient; to Symptom through hasSymptom, describing the presence of symptoms being registered during an event, to Recurrent Disease through hasRelapse, and finally to one or more Intervention or Procedure that may be applied to the patient, through the consist property.

4.2.5 Contingencies

The Contingencies semantic area, represented in Figure 7, contains classes representing "things that may happen": occurrences to the patient that may or may not be related to the disease. They correspond to phenomena in the patient body that cannot be directly planned. We also included a pregnancy among contingencies since, even though partially plannable, it represents a change in the patient body that cannot be ascribed among the medical procedures. These contingencies are still registered during an Event and therefore are linked to the Event in which they are registered via a specific property each.

The classes in this section are:

• Trauma (ncit:C3671), that describes the presence of a trauma to the body of the patient. It also reports the properties traumaDate (xsd:date) and traumaDescription (rdf:langString). The Trauma class is connected to the Anatomical Structure class through the traumaArea object property. It is furthermore linked to the Event during which it is registered via the hasMajorTrauma property.
• Pregnancy (ncit:C25742) describes the presence of a pregnancy. Event is connected to this class through the hasPregnancy property. This class presents a series of properties about the pregnancy itself: startDate and endDate (xsd:date), endEvent (rdf:langString, it describes how the pregnancy ended), complications (rdf:langString).
• Recurrent Disease (Relapse) (ncit:C38155) describes a relapse that may happen to the patient. This class has, in turn, a series of properties describing the relapse, such as relapseStartDate, sequela, recovery, length, etc. The Event object is connected to the Relapse class through the hasRelapse property. Relapse, in turn, may be associated to a Pregnancy (hasAssociatedPregnancy), to a prescribed Pharmacologic Substance (associatedSubstance), to a requested MRI (requiresMRI), and to a possible Intervention (relapseAssessment) required to assess the presence of the relapse itself.
• Comorbidity (ncit:C16457) represents the presence of two or more diseases or medical conditions in a patient. The Comorbidity is characterized by the startYear and endYear property, together with treatment (xsd:string), reporting the prescribed treatment, and severity, describing the severity of the comorbidity from a set of string values (slight, moderate, serious, life risk). A Comorbidity is registered during an Event, and the two classes are connected through hasRegisteredComorbidity.

4.2.6 Intervention and Procedure

This semantic area contains the classes describing the interventions done to a patient to understand, keep under control, and intervene on their clinical condition.

The class Event is connected to the main class of this area, Intervention or Procedure (ncit:C25218), through the consists object property. This class represents "a general activity that produces an effect, is meant to clinically assess, or is intended to alter the course of a disease in a patient" (from its NCI Thesaurus definition).

Instances of the Intervention or Procedure class can have two properties: startDate and endDate. Such dates allow us to register the starting and ending moment of the intervention, if this is something continued in time. Notice that, thanks to an abuse of notation, by leaving empty the endDate, we can also represent interventions and procedures that are atomic in time, i.e., are not distributed through more days. The ontology contains different subclasses for Intervention, and each of them supersedes a semantic sub-area depending on the nature of the procedure itself. We describe the characteristics of the main intervention and procedures in the remainder of this subsection.

4.2.6.1 Therapeutic Procedure

The subclass Therapeutic Procedure (ncit:C49236), depicted in Figure 8, represents the action or administration of therapeutic agents to produce an effect that is intended to alter or stop a pathologic process.

We considered three possible types of therapeutic procedures: a generic therapy (the Therapeutic Procedure class itself), a Disease Modifying Therapy (DMT) and a Mechanical Ventilation (NIV) (ncit:C171457).

DMT presents the property seriousAdversarialEvent (also referred to in the documents as SAE), which indicates the occurrence of a serious adverse reaction to a specific Disease modifying therapy.

All the possible therapeutic procedures might involve the prescription or the associated usage of one or more pharmacological substances. The administration of these substances is modeled here through the use of the class Administration (ncit:C25409), characterized by properties describing the administration itself: administrationRoute (rdf:langString), endReason (rdf:langString), dose (xsd:float), medicineName (xsd:string), frequency (rdf:langString).

An Administration is related to the administered substance, here represented through the class Pharmacological Substance (ncit:C1909), through the object property isRelated.

Among the possible substances that may be administered (subclasses of Pharmacological Substance), the following have been identified as particularly relevant to the domain: Vaccine (ncit:C923), Agent Affecting Nervous System (ncit:C78927) (and especially its subclass Riluzole (ncit:C47704)), and cortisone treatment (:cortisone_treatment).

4.2.6.2 Diagnostic Procedure

Diagnostic Procedure (ncit:C18020) is another subclass of Intervention or Procedure, and it represents any procedure or test to diagnose and assess the progression of a disease or disorder. This, in turn, presents many subclasses. Due to this, we further divided the graphical representation of this sub-area in different Figures: Figure 9.a, 9.b and 9.c, to help their readability.

Starting from Figure 9.a, we see the Pulmonary Function Test (ncit:C38081). As the name suggests, it is used to store information about pulmonary function tests carried out on the patient. Instances of such class have several properties associated, each of which correspond to a parameter used to assess the quality of the respiratory functions of the patient (i.e., VC, FVC, etc. …). Another subclass here is the Blood Test (ncit:C49286), representing a test to measure hematopoietic components and investigate hematologic disorders. The relevant parameters assessed via a blood test are represented through the use of properties of this class.

The Expanded Disability Status Scale (EDSS) (ncit:C98302) is a subclass describing a system for quantifying the level of disability for multiple sclerosis. The EDSS is traditionally computed considering 12 different items: each of these items is represented by a property of this class with range xsd:float.

We continue with the classes belonging to this sub-area in Figure 9.b. The Questionnaire (ncit:C17048) class represents a questionnaire that is submitted to the patients at each visit. In turn, different types of questionnaires may be submitted, with different sets of questions.

The class Clinical Assessment (maxo:0000487) represents a measurement performed in a clinical setting using clinicians' observations and instrument data to inform patient care and research. The instances of this class may contain different fields with the data collected during the assessment itself, as can be seen in the figure.

Finally, Figure 9.c reports the last classes of this sub-area. With Evoked Potentials (omit:0006295) we mean a class of tests used to measure the electrical activity in certain areas of the brain and spinal cord. Evoked potentials test and record how quickly and completely the nerve signals reach the brain. These types of tests are helpful in diagnosing such conditions as multiple sclerosis and other neurological disorders. Key properties for this type of Procedures are the potentialValue (a value among normal and altered), and the location. Electrical activity is produced by stimulation of specific sensory nerve pathways. In the ontology there are subclasses describing the different types of Evoked Potentials: Visual Evoked Potentials (omit:0006298), Motor Evoked Potentials (omit:0019166), Auditory Evoked Potentials (omit:0006296) and the Somatosensory Evoked Potential (omit:0006297).

With Diagnostic Imaging (ncit:C16502) we refer to various techniques of viewing the inside of the body to help figure out the cause of an illness or injury, and thus confirm a diagnosis. Doctors also use it to see how well a patient's body is responding to treatment for a fracture or illness. Subclasses of Diagnostic Imaging are the Magnetic Resonance Imaging, also known as MRI (ncit:C16809), characterized by properties describing its results, and the Positron Emission Tomography, also known as PET (ncit:C17007).

4.2.6.3 Surgical Procedure

The Surgical Procedure class describes a generic surgical operation performed on the patient. As seen in Figure 10, Its subclasses represented in the ontology are: Percutaneous Endoscopic Gastrostomy (PEG, ncit:C10604), a procedure in which a flexible feeding tube is placed through the abdominal wall and into the stomach, allowing nutritions, fluids and medications to be put directly into the stomach, thus bypassing mouth and esophagus; tracheotomy (or tracheostomy, ncit:C15341), an opening surgically created through the neck into the trachea to allow direct access to the breathing tube; Cerebrospinal fluid examination (CSF Analysis, ncit:C173272), the analysis of the cerebrospinal fluid, a clear, colorless liquid found the the brain and spinal cord, acting like a cushion against sudden impact or injury to the brain or spinal cord. This last class is characterized by the properties cerebrospinalFluid and lymphocytes, describing aspects of the test's results.

4.2.7 Anatomical Structure

This area, shown in Figure 11, contains the Anatomical Structure (uberon:0000061) class. Such class, due to its nature and function, cannot be assimilated to any other already available classes and semantic areas.

The class Anatomical Structure is the root of a taxonomy containing classes representing parts of the human anatomy used throughout the ontology. To avoid creating new instances of a certain location every time it is required, we define a named individual for each of the required anatomical structures: all the resources that need to be associated with one or more anatomical structures will point to the same name individual.

The Anatomical Structure is the range of many object properties in the Brainteaser ontology. Some examples are site (connecting the Onset to the Anatomical Location), traumaArea (connecting the class Trauma and indicating where it happened), area (connecting the class Diagnostic Imaging), surgicalArea (connecting Anatomical Structure to the class Surgical Procedure), and symptomArea (connecting it to the class Symptom).

4.2.8 Symptoms

The Symptoms semantic area, shown in Figure 12, contains classes describing the symptoms that may happen to a patient and be registered during an Event.

The class Event is connected to the main class of this area, Symptom (ncit:C4876), through the hasSymptom object property. The Symptom class, in turn, is connected to the Anatomical Structure class through the symptomArea property, allowing to specify the area associated with a specific symptom.

The resources will be rarely of type Symptom, since it is too generic to describe any real characteristic of the patient's disease course. Among symptom instances, we list here the Nervous System Finding (ncit:C36280) and its subclass, the Fasciculation (ncit:C34606) and the Inflammation (ncit:C3137). These symptoms are among the most relevant concerning the diseases modeled in this ontology. For the case of Inflammation, in particular, we register the Pharmacologic Substance being administered, through the associatedSubstance object property.