Dear Alexios Zavras, I hope this email finds you well. My name is Maira Papadopoulou, and I am a fourth-year undergraduate student at the Department of Informatics and Telecommunications of the National and Kapodistrian University of Athens. I recently reviewed the "Unified SBOM Management via RDF Database Abstraction" project for Google Summer of Code 2026, and I am very interested in contributing to it. Having worked extensively with the triplestore abstraction library in the past, I am particularly motivated by the idea of continuing and expanding this effort. Through my previous experience developing the triplestore abstraction library, I gained practical exposure to RDF modeling, SPARQL querying, backend abstraction design, and overcoming the challenges of building a backend-agnostic library. This has made me comfortable working both with semantic data models and with the architectural aspects required to design clean and extensible libraries. Although I did not have much prior experience with SBOM data or the SPDX standard, I have recently started exploring both the v2 and v3 specifications. What I find particularly interesting about SPDX 3.0 is its graph-oriented design, since its ontology-based structure maps naturally to RDF concepts and triplestore storage. From what I currently understand, the project is not just about converting formats. Rather, it focuses on properly ingesting SPDX-based SBOM data into an RDF store, managing it in a structured way, and being able to reconstruct valid SPDX documents from the stored graph using the abstraction layer. To effectively contribute to the project, I was thinking of approaching it in a structured way, while remaining flexible depending on the architectural direction you have in mind. Initially, I would like to focus on understanding the SPDX data model in depth and how its ontology maps to RDF structures in practice. Once I feel confident with the model, I would start by experimenting with basic CRUD operations for SBOM data in the triplestore abstraction layer. I believe this would help me better understand how SPDX entities behave once stored as triples and what design considerations might emerge early on. After that, I would likely move to the Store-to-SBOM Exporter. Working from the export side seems like a good way to validate that the stored graph structure is sufficiently expressive to reconstruct standard-compliant SPDX documents. From there, I would implement the reverse flow (SBOM-to-Store ingestion), ensuring that the mapping from SPDX documents to RDF graphs preserves the intended semantics and relationships. Finally, I would focus on strengthening the workflow with testing, validation, and documentation so that ingest, manage, and export operations work consistently across supported backends. I would really appreciate your thoughts on whether this direction is sound. In particular, from your perspective, do you see the main technical challenge lying in the RDF modeling of SPDX 3.0 itself, meaning I should focus more deeply on understanding the specification and ontology, or rather in the integration between SPDX data and the triplestore abstraction layer? I would love to discuss the project in more detail and better understand the architectural goals you have in mind. If there are specific technical aspects you would recommend prioritizing at this stage, I would be happy to explore them further. Looking forward to your response. Best regards, Maira Papadopoulou
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.