gsoc-2026
GSoC 2026 Week 3: Extraction API, CI, and Framework Debugging
Week 3 was about making the implementation safer to run: extracting dump statistics, adding CI across the website stack, fixing Java compatibility, and documenting the rough edges I found while exercising the DBpedia extraction framework for Amharic.
3 June 6, 2026 - June 12, 2026
After Week 2 established the first backend and UI pieces, Week 3 focused on making those pieces more dependable. I worked on the extraction/statistics API, connected the project to a real CI workflow, fixed a Java compatibility issue, and spent time debugging the extraction framework with Amharic-specific inputs. The debugging work was especially useful because it showed the difference between a feature working in a clean demo and a feature surviving real multilingual data.
Implementation milestones
Extraction and statistics API
I continued the backend work by implementing the extraction and statistics API that calculates statistics for a selected Amharic dump. This endpoint is important because it turns the extraction framework from a local developer tool into something the website can call and explain.
Frontend, backend, and E2E CI
I integrated CI for the Amharic DBpedia website so frontend checks, backend checks, and end-to-end tests can run together. This work was submitted in the website CI pull request, which helps future contributors know when a change breaks the app before it reaches users.
Java 8 export fix
I fixed an extraction API error by exporting the runtime to Java 8. The extraction framework has compatibility assumptions, and making that runtime explicit made the API path more predictable.
Contribution workflow
I added Husky hooks and PR contribution guidance so contributors get feedback before pushing and reviewers get a clearer structure for proposed changes.
CI for the website stack
I integrated a CI workflow that runs the frontend, backend, and end-to-end tests for the DBpedia website. The pull request is available here: Amharic-DBpedia/website#1. This matters because the site now has multiple moving parts. A change can break the UI, the API, or the browser flow, so the CI needs to exercise the full path.
01
Frontend checks
02
Backend checks
03
E2E tests
04
Pages-ready build
What the extraction-framework debugging revealed
The hardest part of the week was not only wiring the API. It was understanding why extraction can fail on real Amharic content. These failures are valuable because they point to the places where our mapping work, templates, language configuration, and ontology assumptions need to become more precise.
New regional language codes are not fully supported
Some newer or regional language identifiers are not handled flexibly by the extraction framework path. One example is be-tarask. The behavior appears hardcoded around an older or narrower language-code set, which is a problem for multilingual DBpedia work because language support should not require changing core logic every time a new variant is needed.
Invalid template nodes appear in parsed content
While running Amharic extraction, I saw invalid nodes such as {{Lable|am|የሙዚቃ መሣሪያ ተጫዋች}}. These malformed or unexpected template calls can be ignored by the parser, but each ignored node is also a clue that source templates and parser expectations are not perfectly aligned.
Ontology property domains can be missing
Another issue was a missing domain error: domain 'dbo:Disease' of property 'dbo:virus' not found. This kind of error points to a mismatch between mapping definitions, ontology assumptions, and what the extraction framework expects to find when resolving a property.
Incorrect templates can break extraction
Some templates are written in ways that make parsing fragile. Even if the template is useful on a wiki page, it can still cause extraction errors if its structure does not match what the DBpedia mapping and parser expect.
The practical lesson
Week 3 made the project feel more real. The website now has CI, the backend has a clearer extraction/statistics path, and the extraction framework issues are becoming specific enough to debug instead of vague enough to ignore. The next step is to keep turning those findings into fixes: cleaner templates, better language-code handling, more robust mappings, and API behavior that explains failures instead of hiding them.