How can JSON Schemas be used with JSON-LD? Why is this useful?

[decentralgabe]

To be discussed. Examples needed on how to use both together in a VC, and why one would want to do this.

[andresuribe87]

A good starting point is https://www.w3.org/TR/vc-data-model/#differences-between-contexts-types-and-credentialschemas

[decentralgabe]

@msporny it would be great to get your insights here or a PR on some helpful spec text if you have the bandwidth.

[msporny]

@msporny it would be great to get your insights here or a PR on some helpful spec text if you have the bandwidth.

JSON-LD and JSON Schema were designed to complement each other. Each of the technologies do fundamentally different things, even though it might seem like a few features overlap.

JSON Schema is used to enforce a certain structure and syntax in a JSON document. JSON Schema answers the question: Is the input document syntactically valid for my application?

JSON-LD is used to annotate and interpret a JSON document in a globally unambiguous way. JSON-LD answers the question: How should my application interpret the information in the input document?

I think, fundamentally, you're looking for prose that expresses the statements above.

You could look at the introduction in the JSON-LD specification to see if that helps elaborate on the statements above: https://www.w3.org/TR/json-ld/#introduction

Same for JSON Schema: https://json-schema.org/draft/2020-12/json-schema-core.html#section-1

Fundamentally, JSON Schema is about structure and JSON-LD is about semantics.

[andresuribe87]

Thanks @msporny

Something I have found myself asking a lot is: why do you care about structure when you know how to interpret the input document?

My thinking is that if I know how to interpret every field in a document, then I don't actually care about the structure of the document itself, since I can easily reshape it. Is the intention of differentiating Schema's and LD to support actors that don't care about the semantics of a document?

[msporny]

Something I have found myself asking a lot is: why do you care about structure when you know how to interpret the input document?

Yes, well that's one of the core theoretical arguments for graph-based data models... but even then, that doesn't quite capture it as graphs have structures of their own.

There's this concept called "graph soup" in graph-based information systems where it is possible to extract core statements you care about and then "grow the data structure out from your core statements"... that is, follow links going out from the statements you care about. Think of starting from a web page you care about and then following all incoming links to the upstream web pages, and then following incoming links from those web pages to their upstream web pages, and so on. In this case, the initial structure is unknown and you kinda don't care, because you can discover the structure from the initial set of statements you care about.

So, yeah, you don't care about the structure when you know how to interpret the information in the input document... you "walk the graph" to discover the structure... IN THEORY... more below...

My thinking is that if I know how to interpret every field in a document, then I don't actually care about the structure of the document itself, since I can easily reshape it.

Yes, and that's kinda what shape languages like SHACL and SHeX and JSON-LD Framing are about. If you want to impose a structure on the graph of data, you can, but that's an optional, secondary thing you can do.

Is the intention of differentiating Schema's and LD to support actors that don't care about the semantics of a document?

I wouldn't say that, necessarily. I mean, you will come across people that claim that there's an absolute bright line there... between the JSON Schema people that don't care about RDF, and the JSON-LD people that are frothing at the mouth about semantics (which are useful caricatures if you're trying to divide people).

... but reality is a lot more nuanced than that. The reality is that we don't have good programming languages that have graph-based data structures as primitives in the language. Like, we have arrays, and maps... but graph foo; isn't a thing. We've got decades of hierarchical and tree-based data structures that impose restrictions on how we write algorithms. So, even if we have a graph of information, we still have to map it into some sort of tree structure in order to process it in modern programming languages.

Fundamentally, everyone cares about semantics (even if they claim that they don't). You have to know what your data means to write useful programs... and you have to structure your data into a useful layout to run most common algorithms against that data. So, developers care about both structure and semantics, and the question really boils down to how one believes they're going to accomplish both tasks.

I've heard people claim that you can do both structure and semantics with only JSON Schema, and I'm highly dubious of that claim.

The only argument that resonates with me is the one where a developer claims that their application is so small and closed world that they don't need an open world data model and all of the semantics they need are self contained... and if that's true, then all you need is JSON, JSON Schema, and some documentation... and if that's all you need... you really don't need to be involved in Verifiable Credentials or any of the open world stuff we're doing here. You can build what you want without any of the added complexity using tooling that has existed since the late 90s.

Hope that helps provide a perspective... it's certainly not the only perspective in the group, and I expect others disagree with it vehemently. :)

[decentralgabe]

@andresuribe87 to add guidance on making sure the type in a VC matches the content in the JSON schema

[andresuribe87]

Fixed on #138