JSON-LD is handled as text with regular expressions rather than as JSON-LD. jsonld2struct strips the known vocabulary IRIs from keys in key position; json.decode rewrites a fixed set of @-keywords to at_ fields; the serializer adds exactly one context shape (@context.@vocab) and one placeholder scheme for expanded names. Anything outside that shape does not load:
- a document whose
@context maps prefixes ("core": "https://openminds.om-i.org/props/") and writes core:givenName;
- a context given as an IRI rather than inline;
- a nested
@graph, or a @graph inside a named graph as some KG exports produce;
@type as a list (openMINDS_Python accepts this since 0.4.0);- language-tagged or typed literal values (
{"@value": ..., "@language": ...}).
openMINDS_Python has the same limitation, with a standing todo: implement or import a function that does a full JSON-LD expansion; it special-cases the fully expanded @vocab form and nothing else. So documents written by either library load in the other, but documents from JSON-LD tooling or from the KG's own exports may not load in either.
Proposal: implement the subset of the JSON-LD expansion algorithm the schemas need (vocab and prefix resolution for keys, @type list normalisation, @graph flattening, and passing typed values through) as one internal function that turns any of these shapes into the canonical decoded struct the deserializer already understands. Document the accepted shapes in one place and test each with a fixture. The full algorithm with framing and remote contexts is out of scope.
🤖 Generated with Claude Code
JSON-LD is handled as text with regular expressions rather than as JSON-LD.
jsonld2structstrips the known vocabulary IRIs from keys in key position;json.decoderewrites a fixed set of@-keywords toat_fields; the serializer adds exactly one context shape (@context.@vocab) and one placeholder scheme for expanded names. Anything outside that shape does not load:@contextmaps prefixes ("core": "https://openminds.om-i.org/props/") and writescore:givenName;@graph, or a@graphinside a named graph as some KG exports produce;@typeas a list (openMINDS_Python accepts this since 0.4.0);{"@value": ..., "@language": ...}).openMINDS_Python has the same limitation, with a standing
todo: implement or import a function that does a full JSON-LD expansion; it special-cases the fully expanded@vocabform and nothing else. So documents written by either library load in the other, but documents from JSON-LD tooling or from the KG's own exports may not load in either.Proposal: implement the subset of the JSON-LD expansion algorithm the schemas need (vocab and prefix resolution for keys,
@typelist normalisation,@graphflattening, and passing typed values through) as one internal function that turns any of these shapes into the canonical decoded struct the deserializer already understands. Document the accepted shapes in one place and test each with a fixture. The full algorithm with framing and remote contexts is out of scope.🤖 Generated with Claude Code