Hi Manav,
Your understanding is correct: the data should reside
in a triplestore database.
Whether "parse them" and "convert them into RDF triples"
is required, this obviously depends on the original input format.
Therefore, the use of SPDX Python tools may or may not be required.
The whole value proposition is re-using data,
so "the idea of storing each SBOM as a separate named graph"
seems to defy the purpose.
If the data of each SBOM end up in a separate graph,
we might as well keep them as separate documents.
The round-trip consistency is crucial,
but one has to be very careful about how to check
the equivalence of the initial input with the final output.
On Thu, Feb 26, 2026, at 10:12, Manav Gupta wrote:
> Dear Alexios,
>
> I hope you are doing well.
>
> I wanted to briefly share the approach I am currently thinking of for
> the SBOM storage part of the project and get your feedback.
>
> My understanding is that instead of keeping SPDX documents as flat
> files, we would parse them (v2/v3), convert them into RDF triples, and
> store them inside a triplestore using the abstraction library.
>
> For initial experimentation, I am planning to:
>
> Use tools-python for parsing SPDX documents
>
> Use RDFLib to handle and inspect triples
>
> Test storage using the triplestore abstraction library, starting with a
> backend like Apache Jena and later trying GraphDB to test backend
> independence
>
> I am also exploring the idea of storing each SBOM as a separate named
> graph (for example, one graph per project/version). This could help
> with version management and allow both cross-SBOM and project-specific
> SPARQL queries.
>
> On the export side, I’m thinking of testing round-trip consistency
> (ingest -> store -> export) to ensure we can reconstruct a valid SPDX
> document.
>
> Does this direction seem aligned with what you expect for the project?
> I would really appreciate any suggestions on what I should prioritize
> next.
>
> Best regards,
> Manav Gupta
>
> ----
> Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και
> συζητήσεων που απευθύνεται σε φοιτητές 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
> <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr>>.
--
-- zvr -
----
Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές 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>.