Grants:Programs/Wikimedia Community Fund/Rapid Fund/zelph:Transitive Reasoning, Qualifier Support, and SPARQL-Subset Integration (ID: 23759260)/Final Report
Application type: Tech project
Parts 1-3: Project and impact
1. What was built or achieved during the project, and how did it align with your original goals, milestones and technical plan? (required)
All three milestones from the proposal were delivered and are included in the public zelph 0.9.6 release (published 2 July 2026):
Milestone 1 – Qualifier import. The new command .wikidata-qualifiers imports statement qualifiers from Wikidata JSON dumps into an existing zelph network. Consistent with zelph's architecture, qualifiers become ordinary first-class nodes: each qualified statement is reified as a statement node connected via p:, ps:, pq:, and wikibase:rank facts, mirroring the RDF statement layer known from the Wikidata Query Service. The import supports both full and selective imports (specific qualifier properties only), is idempotent and incremental, and attaches to existing Q/P nodes by name. As planned, this makes disjointness definitions (P2738 with P11260 "list item" qualifiers) directly queryable from the graph — no more external CSV files — and lays the groundwork for qualifier-dependent structural constraints: property entities are processed as well, so constraint definitions (P2305/P2306/P5314 qualifiers on P2302 statements) become queryable graph structure.
Milestone 2 – Janet & SPARQL integration. The Janet language is embedded in zelph, providing a Turing-complete scripting environment with a documented API (zelph/query, zelph/closure, zelph/register-keyword, and more). On top of this, the SPARQL subset was implemented as a Janet script (sample_scripts/sparql.zph) using Janet's PEG parsing, exactly as outlined in the technical plan. The delivered subset exceeds the proposal's minimum scope (BGPs, transitive property paths, projections): it additionally supports DISTINCT, OPTIONAL, MINUS, UNION, FILTER comparisons, subqueries, GROUP BY with COUNT (DISTINCT), ORDER BY, LIMIT, and PREFIX handling — enough to run the relevant real-world queries from the Wikidata Ontology Cleaning Task Force context verbatim. A working REPL integration (the sparql keyword) returns correct results from the zelph network.
Milestone 3 – Transitive path reasoning. The core engine now computes transitive closures natively (forward and backward, with and without reflexivity, corresponding to SPARQL + and *), following the iterative-materialization approach discussed with Peter Patel-Schneider. A persistent adjacency index per predicate is built on first use and cached on disk, so subsequent closure queries skip the build step. The SPARQL evaluator adds a closure-intersection optimization for the typical disjointness-culprit query shape. End-to-end disjointness detection — from the P2738/P11260 definitions in the graph, through rank-based filtering of deprecated statements, to transitive P279 traversal — works with the exact queries from the underlying research paper (Doğan & Patel-Schneider 2024, arXiv:2410.13707), including query shapes that time out on public SPARQL endpoints.
All features are covered by an extensive automated test suite (including end-to-end tests that import qualifier structures from a synthetic dump and run the paper's disjointness query on them), documented on the project website, and released under AGPL v3. Prebuilt, qualifier-extended Wikidata networks are published on Hugging Face so that users can run these analyses without performing the import themselves.
One deviation from the plan: the budgeted "Semantic Logic & SPARQL Consultant" role could not be filled despite genuine recruitment efforts (reported to and approved by the Program Officer on 28 May 2026). I took on this specialization work myself; milestone validation was performed through the automated test suite modelled on 14 real-world SPARQL queries from the task-force context and through the verbatim reproduction of the paper's queries, rather than through external expert review. This also shifted the schedule towards the end of the project period, which is why the release and the community-feedback phase now follow immediately before/after this report rather than well ahead of it.
2. Share links that demonstrate your project's impact, usage, and technical outcomes. (required)
Required links:
- Project page on relevant Wikimedia spaces (e.g. Phabricator, Wikimedia projects, Toolforge)
- Code repository (e.g. Gerrit, GitHub or GitLab)
- Documentation or user guides
- Dashboards, metrics tools, or analytics used to track usage or contributions
Optional links you may include:
- Diff or mailing list announcements
- Community feedback
- Demos or product presentations
- Survey results or user testing feedback
- Examples of integrations or usage within Wikimedia projects
Project pages on Wikimedia spaces:
- Grant proposal page: https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Community_Fund/Rapid_Fund/zelph:Transitive_Reasoning,_Qualifier_Support,_and_SPARQL-Subset_Integration_(ID:_23759260)
- Wikidata Ontology Cleaning Task Force (regular participation, origin of the requirements): [1]
- [2]Mereology Task Force: [3]
Code repository:
[4] (release v0.9.6 contains all grant deliverables: [5])
Documentation / user guides:
- SPARQL queries (incl. a complete, unedited example session running a disjointness-culprit query): [6]
- [7]Wikidata qualifier import: [8]
- [9]Use case Wikidata: [10]
- [11]Project website mirror: [12]
Data / usage tracking:
- Prebuilt networks incl. the qualifier-extended variant on Hugging Face (download statistics are publicly visible on the dataset page): [13]
- [14]GitHub Insights (traffic, clones, stars) for the repository
- CI status across Linux x64/arm64, macOS, and Windows: [15]
Optional:
- Underlying research whose queries the project now supports end-to-end: [16]
- [17]Release announcements were posted in the Wikidata Ontology Cleaning Task Force Telegram group and the general Wikidata Telegram group (no public archive links available for Telegram).
3. What are the key lessons you learned during this project, both technical and non-technical? (required)
Technical
- Implementing the SPARQL parser in an embedded scripting language (Janet PEGs) instead of C++ was the right architectural bet: the entire query language lives in a ~1000-line script on top of the public API, which kept the core engine clean, made iteration dramatically faster, and demonstrates that third parties can extend zelph in comparable depth without touching C++.
- Naming matters more than expected in a name-addressed graph: keeping the RDF prefix as part of the statement-layer predicate names (
p:P2738vs. bareP279) turned out to be essential — without it, transitive closures over direct triples would leak into statement nodes and silently corrupt the very disjointness queries the project targets. - For transitive closures at Wikidata scale, a persistent per-predicate adjacency index (built once, cached on disk) changes the user experience from "minutes" to "sub-second follow-up queries"; investing in such caching early pays off.
- Test miniatures modelled on real task-force queries proved more valuable than synthetic tests: pinning down the exact semantics of 14 real-world queries caught several subtle issues (correlated MINUS semantics, deduplication in diamond hierarchies, prefix expansion edge cases).
Non-technical
- Recruiting a paid expert for a narrow intersection of skills (Wikidata ontology + SPARQL semantics + willingness to engage with a niche engine) is genuinely hard in a small time window; qualified people had conflicting funding or no availability. For future projects I would either budget the expert role with a much longer lead time or plan validation through reproducible artefacts (test suites, published queries) from the start.
- Proactive, early communication with the Program Officer about the staffing problem and its schedule impact made the deviation straightforward to handle — transparency well before the deadline is much better than explanations at the deadline.
- Compressing release, announcement, and reporting into the final days of a project leaves no room for pre-report community feedback; structuring future timelines so the release lands earlier would strengthen the report itself.
4. How did the Wikimedia community or your target audience engage with your project during its development or release? (required)
The project's requirements originate directly from community engagement: I participate weekly in the Wikidata Ontology Cleaning Task Force and the Mereology Task Force, where the need for qualifier support and transitive reasoning (to detect the disjointness violations documented in arXiv:2410.13707) was identified during and after my previous Rapid Fund project. The transitive-closure implementation approach was discussed with Peter Patel-Schneider, co-author of that paper. The 14 real-world SPARQL queries that drove the implementation and the test suite come from this task-force context.
During development, the project also attracted a substantial independent code contribution: GitHub user chboishabba contributed a complete sharding/partial-loading infrastructure (outside the grant scope, but enabled by and building on the grant-funded data pipeline), allowing users to query parts of hosted Wikidata networks without downloading multi-gigabyte files. This is an encouraging signal that the project is becoming a platform others build on.
The release (zelph 0.9.6, 2 July 2026) was announced in the Wikidata Ontology Cleaning Task Force Telegram group and the general Wikidata Telegram group, together with the documentation and the prebuilt qualifier-extended databases on Hugging Face. Because the release coincides with this report (see the schedule note in section 1), the structured feedback phase — presenting the results in the task forces, answering questions, supporting first users, and collecting feature requests for additional qualifier sets — is taking place now, immediately following this report. I will post notable outcomes and feedback on the proposal's Meta-Wiki discussion page as they come in.
5. What risks or challenges did you encounter (related to delivery, safety, or security), and how did you address them? (required)
Delivery. The main challenge was the unfillable consultant role described above. Mitigation: I flagged the issue proactively to the Program Officer on 27 May 2026 (approved 28 May), took on the specialization work myself, and replaced external expert validation with reproducible validation artefacts — an automated test suite modelled on the real task-force queries, plus verbatim end-to-end reproduction of the published disjointness queries. The associated schedule shift consumed the buffer originally planned for a longer post-release feedback phase, but all technical commitments were met within the project period.
A technical delivery risk was memory scale: a full qualifier import materializes hundreds of millions of statement nodes. Mitigation: the command supports selective imports (specific qualifier properties only), and only statements contributing at least one selected qualifier are materialized. This keeps purpose-built databases (e.g. the P11260 variant for disjointness analysis) small while leaving the full import available for high-memory systems.
Safety/security. As anticipated in the proposal, the attack surface is minimal: zelph operates offline on public data dumps, processes no PII, and the embedded Janet environment runs within the zelph process without exposing unsafe system calls through the external interface. The dump parser was hardened against malformed input (string- and escape-aware brace matching, defensive bounds checks); malformed entities are skipped rather than crashing the import. No security incidents occurred.
6. Who will maintain the project going forward, and what is your plan for long-term maintenance? (required)
I (Stefan Zipproth) will maintain the project long-term, as I have since its inception. zelph is my primary open-source project; the grant deliverables are fully integrated into the main branch, covered by an automated test suite running in CI on Linux (x64/arm64), macOS, and Windows, and documented on the project website. As noted in the proposal, implementing the SPARQL layer in Janet rather than C++ structurally reduces the long-term maintenance burden. Infrastructure (website, CI, data hosting via Hugging Face) is in place and incurs no ongoing costs that would require funding.
Development is actively continuing beyond the grant scope — the immediate next direction is qualifier-dependent property-constraint checking, which this project's qualifier import was explicitly designed to enable, alongside ongoing collaborations that broaden the contributor and user base. I will also continue providing additional qualifier-extended database variants on request.
(questions 7-9 are skipped)
Part 4: Financial reporting
[edit]10. Please state the total amount spent in your local currency. (required)
3500
11. Please state the total amount spent in US dollars. (required)
4323.59
12. Report the funds spent in the currency of your fund. (required)
Upload the financial report
12.2. If you have not already done so in your financial spending report, please provide information on changes in the budget in relation to your original proposal. (optional)
The only deviation from the original budget is the reallocation of the consultant budget (originally ~20%, earmarked for a "Semantic Logic & SPARQL Consultant"): despite genuine recruitment efforts, the role could not be filled — qualified candidates had conflicting funding or were unavailable. The corresponding work (SPARQL semantics validation and disjointness detection logic) was performed by me as lead developer, and the budget was reallocated accordingly. This change was reported proactively to the Program Officer (Agnes Bruszik) on 27 May 2026 and approved on 28 May 2026 ("The consequent budget re-organisation, if any, I approve."). The total amount spent equals the approved grant amount.
13. Do you have any unspent funds from the Fund?
No
13.1. Please list the amount and currency you did not use and explain why.
N/A
13.2. What are you planning to do with the underspent funds?
N/A
13.3. Please provide details of hope to spend these funds.
N/A
14.1. Are you in compliance with the terms outlined in the fund agreement?
Yes
14.2. Are you in compliance with all applicable laws and regulations as outlined in the grant agreement?
Yes
14.3. Are you in compliance with provisions of the United States Internal Revenue Code (“Code”), and with relevant tax laws and regulations restricting the use of the Funds as outlined in the grant agreement? In summary, this is to confirm that the funds were used in alignment with the WMF mission and for charitable/nonprofit/educational purposes.
Yes
15. If you have additional recommendations or reflections that don’t fit into the above sections, please write them here. (optional)
The staffing gap compressed the project timeline towards its end: the release, the announcements, and this report all land within the same few days, so the community-feedback phase that in my previous Rapid Fund project preceded the report is, this time, only just beginning. I chose to report on schedule rather than request another extension. I will treat the coming weeks as the de-facto feedback phase — presenting the results in the Ontology Cleaning and Mereology Task Forces, supporting first users of the SPARQL interface and the qualifier-extended databases, and providing additional qualifier variants on request — and will document notable feedback and adoption on the proposal's discussion page on Meta-Wiki, so the record of this grant reflects not only the delivery but also its uptake. A broader reflection for the Rapid Fund program: for individual technical grants that require a narrowly specialized paid expert, the short project window makes recruitment disproportionately risky. Guidance encouraging applicants to either secure such experts before submission or plan validation through reproducible artefacts (test suites, published queries) might spare future grantees the same difficulty.