Term URL changing between versions?

[BigBlueHat]

I noticed while browsing the documentation and the context files that term URLs are changing per version. For example:

The v3.0.1 definition of Agent states the term URL as
https://spdx.org/rdf/3.0.1/terms/Core/Agent

but the v3.1-RC1 definition of Agent states the term URL as
https://spdx.org/rdf/3.1/terms/Core/Agent

However, the two definitions (at least at the human-readable documentation level) look identical.

Changing the identifiers of the terms based on the aggregate work (vs. on the evolution of the discrete term) means that one cannot rely on stable term definitions during the course of the evolution of the aggregate ontology...which makes managing things overtime untenable and requires re-ingesting old data in new formats/mappings when a new version is released.

That said, I may be missing something obvious that's driving this choice. 😅

So, I'd love to know if the changing term URLs is intentional for some design reason I've missed or just a byproduct of documentation tooling (or other) that hasn't been tripped over yet. 😄

Thanks for any clarity you can provide!

Cheers,
🎩

[bact]

The changing URL concern is also expressed in this issue:

• "please do not use versioned namespaces"
  namespace problems in spdx-model.ttl spdx-3-model#1146

[zvr]

You are correct that each release of the SPDXv3 uses version-specific IRIs for each class and property.

What is still missing is the definitions that say, for example that https://spdx.org/rdf/3.0.1/terms/Core/Agent should be considered equivalent to https://spdx.org/rdf/3.1/terms/Core/Agent (if there has been no change in the definition of these two classes). This will be accomplished using mechanisms like owl:equivalentClass (for classes), or owl:sameAs for individuals, etc.

We know that this has to be published, but since 3.1 is the first time we will be publishing another SPDXv3 specification (after 3.0.1), this has not yet been completed.

[BigBlueHat]

What is still missing is the definitions that say, for example that https://spdx.org/rdf/3.0.1/terms/Core/Agent should be considered equivalent to https://spdx.org/rdf/3.1/terms/Core/Agent (if there has been no change in the definition of these two classes). This will be accomplished using mechanisms like owl:equivalentClass (for classes), or owl:sameAs for individuals, etc.

Certainly owl:equivalentClass or owl:sameAs will be helpful in systems that support those (and are willing to deal with the additional indirection). However, as someone who's contributed to "simpler" (or less talented 😉) data stores like https://github.com/levelgraph/levelgraph that added level of indirection becomes costly...if not a deal breaker.

The proposals I'm seeing in spdx/spdx-3-model#1146 look like they may be on the right track for simplifying things.

Essentially, terms can benefit from having their own lifecycles (and therefore identifiers) than the aggregate ontologies they're apart of--which would allow my...less talented database(s) 😁 to survive version shifting when the graph-level identifiers would not change the meaning of the term being used in data and querying.

Anyhow, I think others have said this better in the model repo.

So, feel free to close this unless you see a discrete action here--and thanks for the links!

[bact]

Essentially, terms can benefit from having their own lifecycles (and therefore identifiers) than the aggregate ontologies they're apart of--which would allow my...less talented database(s) 😁 to survive version shifting when the graph-level identifiers would not change the meaning of the term being used in data and querying.

Related to the topic of terms having their own lifecycles, there was a discussion on how to put the lifecycle information into the model itself, see spdx/spdx-3-model#970 (lthis deprecation information + "since version" information will help smoothing sunset/migration process).

The same discussion also talking about a way to put owl:sameAs (also in a context of migration to a new term after deprecation) and it spun-off to another issue, at spdx/spdx-3-model#978

None of these have been agreed/implemented so far though.
Being said that, it also mean there can be opportunities for more input.

[bact]

Another concern on changing URL between versions:

• Persistent URIs for the RDF #1157

[goneall]

We discussed this issue on the implementers call.

We generally agree to use the major version, but not change the URL for every minor version.

Some of the logic for this proposal:

• SPDX 3 is semantically different from SPDX 2, so having "3" in the URL makes sense
• Minor versions of SPDX 3 are backwards compatible, so the semantics are similar if not the same between minor versions
• Using sameAs is computationally expensive
• Implementations supporting multiple minor versions would be greatly simplified if the minor versions were not in the URL

@zvr - any thoughts on this proposal?

[goneall]

Reference the related issue raised in the examples repo: spdx/spdx-examples#131