When a TD is submitted with a custom external context URL (e.g. "https://example.org/hotel-context.jsonld" defining terms like floor, zone, building ), the following happens:
- At ingestion, jsonld.toRDF() in transform-to-nt.js fetches the URL live and expands all custom terms to their full IRIs. The triples are stored correctly. The original @context array (including the URL) is saved verbatim in the metadata graph.
- At retrieval, frame-jsonld.js receives the saved @context array and passes it to jsonld.frame(). The jsonld library attempts to fetch the custom URL again at framing time. If the URL is unreachable because the server is air-gapped, the URL has moved, or the external service is temporarily down , the library silently drops all terms from that context. The framed output contains bare IRIs (https://example.org/hotel#floor ) instead of compact terms (floor), and the @context in the response no longer reflects the original submission.
The existing handling for https://www.w3.org/2022/wot/td/v1.1 and https://www.w3.org/2022/wot/discovery via overwrite_thing_context and overwrite_discovery_context already solves this problem for the standard WoT contexts by inlining them before the jsonld library ever sees the document. The same approach is not applied to third-party context URLs.
When a TD is submitted with a custom external context URL (e.g. "https://example.org/hotel-context.jsonld" defining terms like floor, zone, building ), the following happens:
The existing handling for https://www.w3.org/2022/wot/td/v1.1 and https://www.w3.org/2022/wot/discovery via
overwrite_thing_contextandoverwrite_discovery_contextalready solves this problem for the standard WoT contexts by inlining them before the jsonld library ever sees the document. The same approach is not applied to third-party context URLs.