Prefixes from @context are ignored

[bigerl]

spdx-java-v3jsonld-store/src/main/java/org/spdx/v3jsonldstore/JsonLDDeserializer.java

Line 107 in f3b4619

String id = graphNode.has(SPDX_ID_PROP) ? graphNode.get(SPDX_ID_PROP).asText() : graphNode.get("@id").asText();

Prefixes from @context seem to be ignored, e.g.:

{
    "@context": {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "spdx": "https://spdx.org/rdf/3.0.1/terms/Core/",
        # ...
    },
    # ...
    "spdx:spdxId": {
      "@type": "xsd:anyURI",
      "@value": "urn:uuid:01973600-280e-7e13-b035-87a63695cf3d"
    },
    # ...
}

does not work. spdxId only works with:

{
    "@context": {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "@vocab": "https://spdx.org/rdf/3.0.1/terms/Core/",
        # ...
    },
    # ...
    "spdxId": {
      "@type": "xsd:anyURI",
      "@value": "urn:uuid:01973600-280e-7e13-b035-87a63695cf3d"
    },
    # ...
}

Here, it seems not specifying "@vocab": "https://spdx.org/rdf/3.0.1/terms/Core/", is also fine.

This leaves me also with the following questions:

Is this really a general purpose SPDX v3 JSON-LD store, or is it rather built to digest files from exactly one source that always structures them the same way? In RDF, I would expect an application to accept my files if the graph matches the necessary structure independent of the exact serialization i use. This seems not to be the case with this store.

[goneall]

Is this really a general purpose SPDX v3 JSON-LD store, or is it rather built to digest files from exactly one source that always structures them the same way? In RDF, I would expect an application to accept my files if the graph matches the necessary structure independent of the exact serialization i use. This seems not to be the case with this store.

This library was (originally) designed to just use the SPDX specific subset of the JSON-LD as specified in the spec for both serializing and deserializing.

However, in thinking about this a bit more it would be very useful to be able to deserialize any JSON-LD document that matched the SHACL definitions without being constrained to the specifics of the SPDX context file.

On serialization, I believe we should always serialize to the spec - this would allow non-RDF enabled parsers to parse the file.

To support a more general serialization, we would need to fix the issue raised here and then only refer to the non-context aliased terms. Not quite sure of the scope of changes - it may be a couple of months before I can dive into the changes, but please feel free to investigate more - contributions are always welcome :) Having some example JSON-LD files we'd like to deserialize as test cases would be a good starting point.

[bigerl]

Thank you for the explanations. I completely overlooked the json-schema in the specs. With non-RDF enabled parsers, it makes sense to restrict serialization formats.

With typical RDF tools, it is rather complicated to serialize an RDF graph containing SPDX into that form. So, It would be great if spdx-java-v3jsonld-store would support digesting any JSON-LD document that matches the SHACL definitions. This would allow to load any RDF that represents an SPDX document into spdx-java-v3jsonld-store and then use it to serialize it into canonical form.

We are using SPDX for the info endpoint of a rust/C++ application. I will leave you the non-canonical SPDX JSON-LD below.

Also, using some RDF converter like should do the trick to get non-canonical JSON-LD out of canonical SPDX JSON-LD.

{
    "@context": {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "spdx": "https://spdx.org/rdf/3.0.1/terms/Core/",
        "spdx-profidtype": "https://spdx.org/rdf/3.0.1/terms/Core/ProfileIdentifierType/",
        "spdx-software": "https://spdx.org/rdf/3.0.1/terms/Software/",
        "spdx-reltype": "https://spdx.org/rdf/3.0.1/terms/Core/RelationshipType/",
        "spdx-softwarepurpose": "https://spdx.org/rdf/3.0.1/terms/Software/SoftwarePurpose/"
    },
	"@graph": [
		{
			"@type": "spdx:SpdxDocument",
			"spdx:creationInfo": {
				"@id": "_:ci"
			},
			"spdx:profileConformance": [
				{
					"@id": "spdx-profidtype:core"
				},
				{
					"@id": "spdx-profidtype:software"
				}
			],
            "spdx:spdxId": {
                "@type": "xsd:anyURI",
                "@value": "urn:uuid:01973600-280e-7e13-b035-87a63695cf3d"
            },
			"spdx:rootElement": {
				"@type": "spdx-software:Sbom",
                "spdx:creationInfo": {
                    "@id": "_:ci"
                },
                "spdx:profileConformance": [
                    {
                        "@id": "spdx-profidtype:core"
                    },
                    {
                        "@id": "spdx-profidtype:software"
                    }
                ],
                "spdx:spdxId": {
                    "@type": "xsd:anyURI",
                    "@value": "urn:uuid:01973600-280e-7e13-b035-87bd0ad286c1"
                },
                "spdx:rootElement": {
                    "@id": "_:myappdb"
                }
			}
		},
		{
			"@id": "_:ci",
			"@type": "spdx:CreationInfo",
			"spdx:created": {
				"@type": "xsd:dateTimeStamp",
				"@value": "2025-06-02T16:55:03+02:00"
			},
            "spdx:spdxId": {
                "@type": "xsd:anyURI",
                "@value": "urn:uuid:01973600-280e-7e13-b035-87c1c02eb24e"
            },
            "spdx:specVersion": "3.0.1",
			"spdx:createdBy": {
				"@type": "spdx:Agent",
                "spdx:creationInfo": {
                    "@id": "_:ci"
                },
                "spdx:spdxId": {
                    "@type": "xsd:anyURI",
                    "@value": "urn:uuid:01973600-280e-7e13-b035-87de0ead959f"
                }
			}
		},
    {
			"@type": "spdx:Relationship",
			"spdx:from": {
				"@type": "spdx:Package",
				"spdx:name": "libmyapp",
				"spdx-software:packageVersion": "13.3.0",
				"spdx:spdxId": {
					"@type": "xsd:anyURI",
					"@value": "SPDXRef-sha3-64a5aab4dc6ed1696346fa09d3fa87b93592d6e4a8776a8e77c95a98a6d10cfbb35d97613d867d51561d2097f7d7686b00dfa1d07dc642b7ab28eea3c4ff063e"
				},
                "spdx:creationInfo": {
                    "@id": "_:ci"
                }
			},
			"spdx:relationshipType": {
				"@id": "spdx-reltype:hasStaticLink"
			},
            "spdx:to": {
        		"@id": "_:myappdb"
        	},
			"spdx:spdxId": {
				"@type": "xsd:anyURI",
				"@value": "urn:uuid:01973600-280e-7e13-b035-87f7fcb33c59"
			},
            "spdx:creationInfo": {
                "@id": "_:ci"
            }
		},
{
			"@type": "spdx:Relationship",
			"spdx:from": {
				"@type": "spdx:Package",
				"spdx:name": "hypertrie",
				"spdx-software:packageVersion": "0.29.4",
				"spdx:spdxId": {
					"@type": "xsd:anyURI",
					"@value": "SPDXRef-sha3-bc000818e049c52617a741f5cb46feaae550cdbee6335fba9925aac38e5532a2366548320bd0727801f3689ffcb401bdd919f448a2d2261cb51f2a8faf6e8386"
				},
                "spdx:creationInfo": {
                    "@id": "_:ci"
                }
			},
			"spdx:relationshipType": {
				"@id": "spdx-reltype:hasStaticLink"
			},
            "spdx:to": {
        		"@id": "_:myappdb"
        	},
			"spdx:spdxId": {
				"@type": "xsd:anyURI",
				"@value": "urn:uuid:01973600-280e-7e13-b035-8800d2d725bf"
			},
            "spdx:creationInfo": {
                "@id": "_:ci"
            }
		},
{
			"@type": "spdx:Relationship",
			"spdx:from": {
				"@type": "spdx:Package",
				"spdx:name": "storage",
				"spdx-software:packageVersion": "2900",
				"spdx:spdxId": {
					"@type": "xsd:anyURI",
					"@value": "SPDXRef-sha3-aa7710d9af4a83f58bbc395f719c2ab79184986df11b3312e473c059eeb076bf14967585a1aa1c66411355adbed507c2bac6f3abeb5de4c4d926a7c91fcc78a3"
				},
                "spdx:creationInfo": {
                    "@id": "_:ci"
                }
			},
			"spdx:relationshipType": {
				"@id": "spdx-reltype:hasStaticLink"
			},
            "spdx:to": {
        		"@id": "_:myappdb"
        	},
			"spdx:spdxId": {
				"@type": "xsd:anyURI",
				"@value": "urn:uuid:01973600-280e-7e13-b035-881a28a4612f"
			},
            "spdx:creationInfo": {
                "@id": "_:ci"
            }
		},
{
			"@type": "spdx:Relationship",
			"spdx:from": {
				"@type": "spdx:Package",
				"spdx:name": "rdf4cpp",
				"spdx-software:packageVersion": "0.0.57",
				"spdx:spdxId": {
					"@type": "xsd:anyURI",
					"@value": "SPDXRef-sha3-c7a894676dba51c0dd4174bd2418242430fa6ba843d6760aebf3a9b3767833986b4e2725acff91bcae096abeea9dbdaa12aaefc71a482574dd7e8383a187893a"
				},
                "spdx:creationInfo": {
                    "@id": "_:ci"
                }
			},
			"spdx:relationshipType": {
				"@id": "spdx-reltype:hasStaticLink"
			},
            "spdx:to": {
        		"@id": "_:myappdb"
        	},
			"spdx:spdxId": {
				"@type": "xsd:anyURI",
				"@value": ""
			},
            "spdx:creationInfo": {
                "@id": "_:ci"
            }
		},
{
			"@id": "_:myappdb",
			"@type": "spdx-software:Package",
			"spdx:name": "myappdb",
			"spdx:packageVersion": "0.17.6",
			"spdx:primaryPurpose": {
                "@id": "spdx-softwarepurpose:executable"
            },
			"spdx:spdxId": {
				"@type": "xsd:anyURI",
				"@value": "SPDXRef-sha3-b35453c6ea3476388b9da6db95c41edfae0b348ec12d12a1d3249f7fd4f87a3bd7fd6d38724669277ff60a1850fc17dd81c4fc827f5983d5eaeebf396f2b6027"
			},
            "spdx:creationInfo": {
                "@id": "_:ci"
            }
		}
	]
}

[goneall]

Thanks @bigerl for the example - I created a draft PR to implement non-canonical deserialization - currently only implementing a test case.

It will probably be 3 to 4 weeks before I have a chance to look at implementing. If you have the time and interest, please feel free to add pull requests to branch issue28 any implementation or test improvements.

[goneall]

Back to looking at this again - it looks like there is quite a bit of work to interpret a general @context node in JSON-LD and it duplicates functionality in some existing solid (IMHO) libraries like Apache Jena.

Unfortunately, adding a dependency to Jena would not be acceptable to many users of the SPDX Java libraries since it has a number of transient dependencies.

I'll do a bit more development to see if I can implement the context support without adding any new dependencies, but if it turns out to be too much work, we may want to either extend the existing spdx-rdf-store to support SPDX 3.0 or create a new spdx-v3-rdf-store library which uses the Apache Jena library to read in any RDF format.

[bact]

If prefix expansion is the only thing we're looking for, will Titanium JSON-LD (Apache-2.0) be enough?

It requires smaller set of transient dependencies - mainly Jakarta JSON (EPL-2.0). https://github.com/filip26/titanium-json-ld

[goneall]

If prefix expansion is the only thing we're looking for, will Titanium JSON-LD (Apache-2.0) be enough?

It requires smaller set of transient dependencies - mainly Jakarta JSON (EPL-2.0). https://github.com/filip26/titanium-json-ld

Thanks @bact for the pointer. I wasn't familiar with Titanium. I took a quick look and it would be a fairly significant redesign for this particular implementation, but may be a possibility if we implemented a separate SPDX store. I would also prefer to stick with Apache-2.0 and MIT for dependencies, but it isn't an absolute requirement.

[bact]

Agree on trying to stick with Apache-2.0 and MIT, and not having a too diverse set of licenses if possible.

Btw, note that Apache Jena uses Titanium JSON-LD and Jakarta for its JSON-LD 1.1 support. So in the case we go with Jena, still have to deal with that.

https://github.com/apache/jena/blob/31b35ff5e9ce391e27016e662ae3bcb37c5fc73c/pom.xml#L65-L67

https://github.com/apache/jena/blob/31b35ff5e9ce391e27016e662ae3bcb37c5fc73c/pom.xml#L533-L551

[goneall]

After a bit more research, I would propose a design where we introduce a super-class to the JsonLDStore which overrides the deserializer using Jena to support any of the RDF formats and serializations.

To address the concerns on too many dependencies, we can mark it as optional. This would require anyone using this feature / class to explicitly include Jena in their Maven POM file.

Reasons for choosing Jena:

• I am already familiar with the interface
• It would support multiple serialization formats such as RDF/XML and TTL
• There still may be dependency concerns on Titanium

@bact @bigerl - let me know any feedback on the above proposal.

[bact]

After a bit more research, I would propose a design where we introduce a super-class to the JsonLDStore which overrides the deserializer using Jena to support any of the RDF formats and serializations.

Support the proposal.

[bigerl]

Sounds good to me 👍🏻