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>.