GSoC Week4

 

Overview

This week focused on two tracks:

  • Enhancing SBOannotator’s EC annotation coverage by introducing a unified database adapter (adapter pattern).

  • Community outreach: posting a brief project intro with code/blog links to SBML discuss, COBRA, COMBINE, SysMod, X (Twitter), and LinkedIn

Code & Features

1) New adapter.py (Unified Database Adapter Layer)

Purpose: Aggregate multiple biology databases to retrieve EC numbers via the adapter pattern.
Key Components:

  • EnzymeDataAdapter: abstract base class defining a unified interface.

  • KEGGAdapter: queries the KEGG REST API (reaction ID → EC).

  • BiGGAdapter: queries the BiGG universal reactions database.

  • UnifiedEnzymeDataProvider: coordinates adapters and performs deduplication.

  • callForECAnnotRxnUnified(reaction): entry point that integrates with the original system.

2) SBOannotatorEnhancedClass.py vs SBOannotator.py

Key change: at line 94, replace with:

callForECAnnotRxnUnified(reaction)  # Enhanced: query multiple databases

This supplements the original logic by fetching EC numbers via BiGG/KEGG APIs, then applying more appropriate SBO terms.

3) main.py modifications

  • Dual-run comparison: run both the original and enhanced workflows on the same model.

  • Result diff/metrics: show the annotation differences between the two.

  • Timing/profiling: record wall time for both paths.

Runs & Outputs

Expected per-model flow

  • Round 1 (original): pre/post SBO term stats, unannotated reactions, execution time.

  • Round 2 (enhanced): API-based EC lookup with final SBO term stats and execution time.

  • Output file: RECON1_SBOannotated.xml → ../../models/Annotated_Models/.

  • Performance comparison: original vs enhanced wall time.

Batch Evaluation Result

  • 108 models were processed.

  • Only 2 reactions were converted from the generic SBO:0000176 (non-covalent binding/association placeholder) to more specific categories.
    Current data shows a real but modest improvement. Subsequent work will aim to increase hit rate and stability via additional data sources, refined matching heuristics, and caching/rate limiting.

Community Interactions

Sent a brief intro email with blog and source code links to SBML discuss / COBRA / COMBINE / SysMod; also posted updates on X (Twitter) and LinkedIn to gather feedback on database coverage and edge cases.

Comments

Post a Comment

Popular posts from this blog

GSoC Week1

Hi, This week focused on the design and implementation of a dynamic update mechanism for SBO (Systems Biology Ontology) data. Key Decisions and Progress 1. Data Update Strategy Decision : On application startup → Check for updates → Download new data → Application becomes available Reason : Prioritize data consistency Status : ✅ Implemented and Pull Request submitted 2. User Control Over Updates Draeger’s Suggestion : Allow users to skip updates to support reproducibility of specific versions Nantia’s  Suggestion : Enforce updates to ensure data consistency Status :  Further discussion and decision in Wednesday's meeting 3. Data Version Management Strategy System Version History Management strategy1 :  Only retain the latest version to save storage  startegy 2:Retain up to 3 versions (2 historical + 1 latest) Status :  Further discussion and decision in  Wednesday's meeting User Import History Management strategy：...
Read more

GSoC week2

Hi, As discussed in the last blog, I started working on my first milestone of fetching SBO table from OLS to SBO annotator. This blog contains a summary of the meeting with the new features I added and the issues I worked on and fixed this week to add SBML L3V2 support. So, let's quickly dive in summary: 1. Change Detection Mechanism for SBO Terms ❓ Issue : OLS API’s updated field changed, but no observable differences in content. ✅ Observation : Compared OLS (API) and GitHub .owl versions – content is identical . Latest update timestamp on OLS is 2025, but GitHub file was last modified in 2023. New terms are already included in the GitHub version. ✅ Decision : We can rely on GitHub .owl file for consistency and reduced request time. 2. Fetching ‘is_a’ / Parent Info Performance Issue ⏱️ Fetching subclass_of (parent info) via OLS takes ~10 minutes. ⚡ Other fields can be fetched in <1 minute. ✅ Optimization : Parent info should be pulled from ...
Read more

GSoC Week 5

 This week, I mainly focused on diagnosing why adding KEGG still failed to yield finer-grained SBO classifications across 108 models, extending the EC lookup pipeline, and experimenting with additional data sources. Here’s the complete summary of the work update during the week. Root-Cause Investigation Added adviaecnumber() helper to attempt refinement via EC number –driven mapping. Re-ran the enhanced pipeline on 108 models  ，reactions that remained in generic SBO classes were still  missing EC numbers . Result: no additional reactions could be refined to more specific SBO classes. Conclusion: the main blocker is not the mapping rule itself but the absence of EC numbers for those reactions across the currently consulted sources. New Data Sources Added SEED adapter : uses the Solr query interface with strict null filtering to avoid spurious entries. Reactome adapter : combines web parsing with the QuickGO API to perform a multi-step conversion...
Read more