Skip to content

Describe "safe mode" for JSON-LD processing. #629

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
BigBlueHat opened this issue Jan 29, 2025 · 2 comments
Open

Describe "safe mode" for JSON-LD processing. #629

BigBlueHat opened this issue Jan 29, 2025 · 2 comments
Labels

Comments

@BigBlueHat
Copy link
Member

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
Copy link
Contributor

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

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

@dlongley
Copy link
Contributor

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.

@gkellogg gkellogg moved this to Future Work in JSON-LD Management Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Future Work
Development

No branches or pull requests

3 participants