SPDX 2.2 has license expressions, which represent multiple elements (license IDs and operators) in a single string. If RDF is going to reason about license expressions, it must be able to know which

I am actually very conflicted about this… On one hand splitting an idString into a two things (namespace and in-namespace-id, if you excuse the awful wording) sounds natural and appeals to my

You should speak with a cryptographer. For a 256 bit hash value, the chance of birthday collision is 1 / 2^128, or 1 / 3.4*10^38. That's 10 with 38 zeros. For comparison, the chance of winning the

Hi Anthony, Thanks for pointing this out. I tried to add a comment, but it appears to be closed. Thomas is active in the SPDX-tech team, but would be nice if someone from the SPDX-legal could add a

>>1) namespaces must be globally unique, and UUIDs in practice collide, in part because they don't have a full 128 bits of uniqueness because they contain built-in structure, and in part because even

My bad. I didn't mean "under control" as having an integrity mechanism, I meant "having the ability to decide what goes into the local ID". Which is synonymous with saying that as far as the SPDX

Thanks for summarizing this David and commenting on it further William. Thanks for the reminder in the call Bob about pointing to the NTIA documents. Here's the existing white paper where multiple

I didn't hear that suggestion, any valid URI can be a namespace (possibly with some restrictions depending on the namespace + local id separator). This creates a space where clashes are unlikely,

Kate may be right that we'll need a whitepaper. But not just yet. Here is what I heard today: 1) namespaces must be globally unique, and UUIDs in practice collide, in part because they don't have a

The SPDX project will be hosting an initial working "DocFest" to bring together the producers of SPDX documents and walk through the differences between tools for the same artifacts. Artifacts

I meant to send this to both the legal and tech lists, as I figured it might be of interest to both, but realized I forgot to add the tech list email, so forwarding now. - Jilayne Begin forwarded

Alexios, Jilayne: IMHO it would be a good time to revisit this. The case of license identifier does not and never did really matter otherwise. It does not matter to users. And most tools do not

Hi Jilayne, You can refresh your memory on the discussions (2015-2020) by readinghttps://github.com/spdx/spdx-spec/issues/63😉 I still like my example from that thread: Do we really want to

Hi Legal, Tech teams, I just want to clarify my understanding of capitalization sensitivity for SPDX license ids and license expression operators: Appendix IV states:

Looks great! Viele Grüße, Henk

If people haven’t seen it, our spec GitHub repo contains the diagrams produced by transforming the ontology to PlantUML: https://github.com/spdx/spdx-spec/tree/development/v2.2.1/ontology --

Hi Philippe, (I mistyped the spdx-tech address, fixed here) ~ Philippe Ombredanne [2021-07-28 12:04 +0200]: The ticket in the reuse-tool is public, the discussions with FSF were private with John

It does make sense. If SPDX accepts it as a valid design requirement, it also means that we MUST define a URI profile that uniquely identifies the boundary between namespace, document-supplied ID,

I agree that in 2.2 all Elements were tied to Documents. I believe the most fundamental change from 2.2 to 3.0 is that this is no longer true. This was a key principle for the 3T-SBOM collaboration

We discussed GraphViz and PlantUML today; here is the GraphViz version of the SPDX 2.2 information model (level of detail: conceptual). You can paste it into any number of tools, I like