Guidance for dealing with new 3.x versions in the JSON-LD

[kzantow]

An issue was discussed about new versions having entirely new sets of identifiers during the implementors call and it would be great to get something at least written up how users should deal with this.

For example, if I'm parsing a JSON document and looking for https://spdx.org/rdf/3.0.0/terms/Software/Package to know this is a 3.0 software package, this will no longer work when https://spdx.org/rdf/3.0.1/terms/Software/Package is output. As I understand it, these two things despite not really having any differences, are now two different, distinct things and could both show up in a document, depending on how it was constructed.

Guidance on how to properly deal with these shifting type names would be appreciated.

[goneall]

Couple of thoughts:

• As a best practice, always include the standard (static) context file which should only use a single version - this way, within a single document you'll only be dealing with a single version
• When serializing, update to the latest patch version (since it should be compatible)

Something we've talked about in the past was using the owl:sameAs predicate to denote the 3.0.1 term is the same as the 3.0.0 term. In addition to allowing the RDF reasoners to deal with this situation, it could provide a hint to tools developers.

@zvr @sbarnum - thoughts? I wasn't on the call where we decided to increment the terms version, so perhaps we could add some of the reasoning for taking this approach.

[bact]

I think the term will eventually be https://spdx.org/rdf/3.0/terms/Software/Package (only MAJOR.MINOR version, no patch point) with this spdx/spdx-3-model#1046 implemented in ISO submission.