Semantic web ontology for structured knowledge representation and clinical decision support in eye diseases

EDO has been categorized into eight distinct modules that include Person, Clinical Manifestation, Disease Symphony, Etiological Factors, Medical Device, Medical History, Treatment, and Procedures. Here is the brief overview of each of these modules.

Person (Patient)

A patient class from schema.org is reused to manage patient-related information. Patient’s class contains data properties from schema.org such as givenName, suggestedAge, suggestedGender, and telephone. This class has object properties schema : diagnosis and hasSymptom. Details of person is shown in Fig. 3.

Etiological factors

Etiological Factors are divided into Medical Causes and Medical Risk Factors. Classes details are shown in Fig. 4.

Etiological factors module.

Medical cause

Medical causes are the factors responsible for a disease mechanism that results in a medical condition, symptom, or sign. This class is reused from schema. This class has an object property isCausedBy.

Medical risk factors

A risk factor refers to anything that increases a person’s probability of acquiring a disease, medical condition, or complication. The schema : MedicalRiskFactor class is reused from schema.org and has an object property triggeredBy.

Disease symphony

Disease Symphony contains two main classes as shown in Fig. 5.

Medical condition

schema:MedicalCondition class is reused from schema.org with subclass DiseaseOrDisorder and schema:MedicalSignOr Symptom. The DiseaseOrDisorder class that is reused from NCIT covers all diseases and disorders; there is also an Infectious Diseases subclass to separate infectious diseases from other diseases. It has an object property schema : stage. It has attributes like schema : differentialDiagnosis, schema : possibleComplication, andSchema : expectedPrognosis used as data properties. schema : MedicalSignOrSymptom is taken from the schema and is further subdivided into Medical Sign and Symptom. There are two subcategories of schema : MedicalSign. The terms schema : vitalsign and sign refer to the measurements of numerous physiological functions to analyze the most basic body functions, whereas signs are any physical manifestation of a person’s medical condition that can be discovered through objective diagnostic tests or physical examination.

The medical sign has the schema : identifyingExam object property. Both schema : MedicalSign and schema : VitalSigns are reused from the schema. Furthermore, the Symptom class that is reused from DOID contains many symptoms as subclasses for their particular medical conditions. Symptoms are the exact signals that a person experiences in their body that help to diagnose a particular disease. This class has one object property called schema : signOrSymptom.

Medical condition stage

It indicates what stage the Medical Condition is in. This class has an object property stage with the Medical Condition class.

Clinical manifestation

Clinical Manifestation has two sub modules that are clinical finding and clinical device as shown in Fig. 8.

Clinical finding

The clinical finding class includes subclasses that pertain to specific observations or outcomes discovered during various ocular medical examinations or health assessments of a patient. This class is reused from SNOMED CT ontology.

Clinical device

This module includes the class schema:MedicalDevice that organizes medical devices based on their usage. It has an object property :usesDevice. The medical device class is further separated into two subcategories and shown in Fig. 6.

Diagnostic device

Devices used for diagnostic purposes are included in the Diagnostic class.DiagnosticDevices are re-utilized from scdo ontology.

Therapeutic devices

The equipment utilized for treatment is in the Therapeutic class.TherapeuticDevices are re-utilized from scdo ontology.

Medical history

Medical History is divided into current medication and past medical history as shown in Fig. 7.

Current medication

Current Medication class refers to any medications, supplements, or drugs that the patient is already taking or it’s a part of their treatment plan. This class has an object property isCurrentlyOn.

Past medical history

Past Medical History class mentions the record of a person’s medical conditions, surgeries, accidents, and medications. This class has an object property hasMedicalHistory (Fig. 8).

Clinical manifestation module.

Treatment

Drug

A schema:drug class refers to substance that is used to treat a disease. This class is taken from schema. It has an object property schema:drugClass.

Drug class

The schema:DrugClass is reused from schema.org and it refers to a group of medicines that indicate common physiological effects, common processes of action, or general pharmacological classes.

Dose schedule

schema:DoseSchedule class reused from the schema describes the specific schedule to take the drug. It has schema:doseUnit, schema:doseValue, schema:frequency, and schema:targetPopulation data properties. These data values show how and when to take the medicines or drugs. It has an object property schema:doseSchedule.

Noninvasive procedure

The schema:NoninvasiveProcedure class contains diagnostic or therapeutic methods that don’t require tools to be inserted into body cavities or to penetrate the skin. This class is reused from schema.org.

Clinical procedures

Clinical Procedure has three modules diagnostic procedures, physical exam and surgical procedure details are shown in Fig. 9.

Clinical procedures module.

Diagnostic procedure

In the schema:DiagnosticProcedure class, all those medical procedures are included that are used to diagnose any particular disease or condition. It has an object property detects.

Physical exam

schema:PhysicalExam class refers to examinations carried out by a physician. This class contains an object property schema:identifyingExam.

Surgical procedure

The surgical procedure class includes the processes that involve making an incision. It has an object property hasSurgicalProcedure.

Ontology metrics

Ontology metrics contain the summary about the number of Axiom, logical axiom, Classes, objects,data properties count, individual count, and Annotation properties. Summary is shown in Table 5.

Integrating use case into ontology

In this section, we present a comprehensive case study of an ophthalmic patient to demonstrate how semantic ontology can streamline clinical decision-making. The case is analyzed across three critical stages: Patient History, Diagnosis, and Treatment. Each phase illustrates how structured knowledge representation enhances clarity, accuracy, and continuity in patient care.

Patient history

The Patient History phase involves a structured understanding of a patient’s background, medical history, and current medications that may contribute to disease development. This foundational step is essential for assessing risk factors and guiding further clinical evaluation.

The patient is a 61-year-old retired educator who has not undergone an eye exam in the past decade. She uses glasses for near tasks and reports moderate eye irritation, particularly in the afternoon or after prolonged reading. Her Past Medical History includes presbyopia, hypertension, a history of eye trauma, and one cesarean delivery. Her Current Medication includes Hydrochlorothiazide. These details are illustrated in Fig. 10.

Use-case of patient medical history.

Diagnosis

The Diagnosis phase integrates clinical observations, diagnostic procedures, and semantic associations to enable accurate identification of disease. Ontological models help structure these findings clearly and meaningfully.

To determine the cause of the patient’s symptoms, several Medical Procedures were conducted. Based on the Clinical Findings, the patient was diagnosed with Primary Open-Angle Glaucoma (POAG). The diagnosis was supported by the following Medical Signs: elevated intraocular pressure, abnormal optic nerve head, open anterior chamber angle, and visual field deficits. These diagnostic indicators are presented in Fig. 11.

Use-case of disease diagnosis.

Treatment

The Treatment phase categorizes both pharmacological and surgical interventions and incorporates follow-up recommendations to optimize patient care and long-term outcomes.

To reduce intraocular pressure, the patient was prescribed topical medications, including Timorex, Latep Eye Drops, and Azm Pills. An alternative surgical intervention, Trabeculectomy (classified as a schema : SurgicalProcedure), is also recommended depending on disease progression and drug response, as shown in Fig. 12. For ongoing care, regular IOP monitoring, visual field testing, and optic nerve assessments are essential, as outlined in the schema : followup phase.

This case illustrates how the applied ontology effectively supports all three stages of clinical decision-making. It allows structured representation of patient history, facilitates semantic integration during diagnosis, and categorizes treatment options with follow-up care. This layered and semantically rich model enhances the interoperability of health data and empowers informed, precise decision-making in ophthalmic care.

Conducting domain expert validation

In addition to the described technical validation methods, qualitative evaluation of the Eye Disease Ontology (EDO) was conducted through expert consultations with ophthalmologists at DHQ Hospital, Sargodha: available at Dr. Hashim Imran & Dr Jannat. These discussions provided critical insights into real-world diagnostic and treatment workflows, enabling the ontology to accurately reflect clinical practices. Feedback from these domain experts guided the refinement of EDO’s class hierarchy, data properties, and object properties, thereby enhancing its completeness, accuracy, and applicability in real-world ophthalmic contexts.

Evaluating ontology

After the creation of the ontology, we critically analysed its structure, relationships, and semantics to uncover any potential flaws or inconsistencies that may have been inadvertently introduced during development. A comprehensive self-assessment was conducted to ensure alignment with the ontology’s intended purpose. Following this, we employed the Ontology Pitfall Scanner (OOPS!) to further evaluate the ontology. This tool detects common modelling issues, inconsistencies, and deviations from best practices that may not be identified through manual inspection.

The majority of the issues identified by OOPS! were resolved during our refinement process. Specifically:

• Resolved by adding clear labels and annotations to all classes, object properties, and data properties.

• P11-Missing Domain or Range in Properties: Addressed by explicitly specifying domains and ranges for all properties.

• P30-Equivalent Classes Not Explicitly Declared: Resolved by declaring equivalence for classes such as Fatigue and Tiredness.

Initially, three minor issues were flagged by OOPS! remained:

• Untyped Class,

• Ontology Not Available on the Web, and

• No OWL Ontology Declaration.

These issues have now been fully addressed and resolved. The untyped class was properly typed, and the ontology is now hosted with a dereferenceable IRI accessible on the web to comply with OOPS! expectations, and the OWL ontology declaration has been added. These updates ensure the Eye Disease Ontology complies with best practices for ontology publishing and improves its interoperability and accessibility. The ontology pitfalls summary is shown in Table 6.

Ontology GitHub repository link

To meet the FAIR (Findable, Accessible, Interoperable, Reusable) principle, which is important in making ontologies more accessible, discoverable, reusable and interoperable, makes it easier to get information, collaborate on research, integrate data, and convey knowledge. Ontologies that are FAIR-compliant are more likely to be broadly adopted and used, promoting improved data sharing and collaboration. For this purpose, the source file of the ontology is made available on Github: available at to make the ontology more findable and accessible, ensuring that users can effortlessly discover it. Moreover, we generated the load document. It will emphasize reusability since reusable ontologies can save both time and effort for both ontology creators and users. Making the ontology available to users will help new users get started from scratch, promote consistency, and reduce redundancy.

Executing SPARQL queries

SPARQL enables users to write complex queries that extract important information, discover relationships between entities, and answer domain-specific questions within ontologies. The Eye Disease Ontology (EDO) was created as a structured knowledge base to support queries related to diagnostic techniques, symptoms, causes, risk factors, and therapies for various eye conditions. Based on the defined use case, we created SPARQL queries and ran them against EDO. The matching questions are shown in Table 7.

The SPARQL queries conducted on EDO predominantly employed the SELECT and WHERE clauses, with some also including FILTER conditions. As the number of filters and constraints increased, the complexity of the queries ranged from medium to high. This increase in expressiveness sometimes led to longer execution times, although overall response efficiency remained moderate, largely influenced by the quality of the underlying data and the effectiveness of instance matching.

We executed SPARQL queries for all 40 competency questions (CQs) presented in the manuscript. However, due to space limitations, only a representative subset is included in the paper to demonstrate the querying process and practical utility of the ontology. These CQs spanned multiple categories, and 38 of them produced correct and expected results. The two that initially failed highlighted gaps in the ontology, prompting refinement through the addition of missing axioms and adjustment of class relationships to enhance reasoning and coverage. Average SPARQL execution times for the sample queries ranged from 80 to 150 milliseconds, indicating efficient performance suitable for clinical decision support. Additionally, we clarify that ambiguous answers were not encountered during testing. If a query did not return the expected result, it was due to syntactical errors or logical gaps in the ontology, which led to execution errors or empty responses. These cases were systematically addressed during iterative development to improve the accuracy, reliability, and completeness of EDO.