Describe "safe mode" for JSON-LD processing.

[BigBlueHat]

JSON-LD Safe Mode has been part of the jsonld.js implementation since 2022:
https://github.com/digitalbazaar/jsonld.js?tab=readme-ov-file#safe-mode

There is an interest from other communities for this to be a core part of the JSON-LD API as the current default of ignoring unmapped terms (for example) is seen as a risk when attempting to enforce explicit JSON shapes.

@dlongley and @davidlehn can provide more details.

[dlongley]

Linking in another issue related to the need for a "safe mode":

w3c/json-ld-syntax#446 (comment)

[dlongley]

The quick description of "safe mode" is that it should be possible to instruct any conformant JSON-LD processor to raise an error if any of the data from the incoming document would be "ignored" or "dropped" in the output. This is for whenever data is fundamentally "deleted"; it does not apply to when data is only transformed into some other shape (like what happens in expansion).

This consideration applies to data in a JSON-LD document that is "not linked data" because nothing in the @context or otherwise in the syntax gives it proper or fully qualified semantics. For example, as the JSON-LD syntax spec says here:

JSON keys that do not expand to an IRI, such as status in the example above, are not Linked Data and thus ignored when processed.

https://www.w3.org/TR/json-ld11/#iris

There are several places in the spec algorithms today that talk about optionally issuing warnings when this occurs. In these places, a "safe mode" (or other TBD name for this feature) flag would also be considered to create a more interoperable error-raising feature across all processors. Other places that would be affected, off the top of my head, would be where relative URLs are dropped in conversions to RDF -- such as is mentioned in the issue I just linked to in my previous comment.

So, what is needed is a more well-defined feature in the API to enable the user of any conformant JSON-LD processor to indicate that they want to receive an error whenever data is "ignored" or "dropped". This feature serves at least two purposes: It allows authors/developers to correct mistakes (quite often data being "ignored" or "dropped" is unintentional) and it more easily allows the creation of applications that can be assured that all of the information in a JSON-LD document is included when it is transformed to RDF.