I am not sure your statement that
"SPDX IDs are document-scoped"
is entirely correct.
In SPDXv2 identifiers uniquely identifies each Element,
and since Elements are not always part of Documents,
the scoping you mention is nonexistent.
Even in SPDXv2, where you can have identifiers "local"
to a Document, they can always be qualified with a Document id.
One could use some external identifiers (like a PURL),
if they were available, but in this case one should be
very careful about treating two Elements as the same one.
What would happen, for example, if two Packages
have the same packageUrl but different name?
In general, as I've written before, the task
of establishing identity between various elements
(besides the SPDX id) is a very complex problem --
and lots of people have been working for decades on it.
I definitely wouldn't expect it to be solved
in the framework of this GSoC project.
On Sat, Mar 7, 2026, at 12:43, Manav Gupta wrote:
> Hi Alexios,
>
> I hope you are doing well.
>
> Over the past few days I spent some more time experimenting with
> loading small SBOM samples into a triplestore using Apache Jena, mainly
> to understand how reuse of data across SBOMs would actually work.
>
> One thing I tried to think through is how identity of nodes should be
> handled when multiple SBOMs are ingested. As SPDX IDs are
> document-scoped, So i think that the abstraction layer will derive a
> stable identity for packages before insertion.
>
> For example, if a purl is available, it could be used as the identifier
> of the package node in the graph. If purl is not present, then
> something like name + version + ecosystem might be used to generate a
> consistent URI.
>
> This way, when two SBOMs reference the same package, they would point
> to the same node in the graph instead of creating duplicate nodes,
> which would help with reuse and cross-SBOM queries.
>
> I’m not sure if this kind of identity handling should happen in the
> abstraction layer before storing the triples, or if the expectation is
> to store the SBOM data more directly and handle this differently.
>
> I wanted to check if this line of thinking makes sense for the project,
> or if there is a preferred approach for handling identity across SBOMs.
>
>
> 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>.