Document the value of processing as JSON-LD

[OR13]

Previous discussed on:

• Add section on JSON Processing. #1202
• Document how VCs are processed as JSON today #1201

Working group members asked for clarity on why processing the data model as JSON-LD was valuable, especially given that the context and vocabulary are now normative.

@msporny said he could take a stab at text on a recent working group call.

[OR13]

On the last working group call, I said:

There is currently no text describing the value that is unlocked by leveraging the normative context and vocabulary, because we don't have any cases where the context is applied.

This causes people to see the "JSON-LD data model" as "not valuable", and resulted in a lot of confusion on the "processing the core data model as JSON PR".

To remedy this, the working group should agree that there is value in processing the core data model as "JSON-LD", we should provide examples for how that value might be obtained... this will make the current text in the "processing the data model as JSON", less confusing.

[mtaimela]

Great proposal to have the JSON-LD side thoroughly described. My own personal opinion is that JSON-LD will help greatly in the integration and after it is well adopted, this can even be used in VP Exchange to request proofs for a meaning.

On the other side, I see JSON as a gateway to implement JSON-LD vocabs. The vocab is not an easy task for governmental domains, which anyway yield many benefits for users (identity certificates, taxation..). This will take time, but if the path is there, and there is demand, then it will happen.

I really like the fact that @context is now mandatory for the base structure of VCDM, while it allows first adopters to go with JSON and take the iteration path towards evolution of unified vocabs. If everyone creates their own vocabs, it's pretty much pointless work.

[OR13]

This will take time, but if the path is there, and there is demand, then it will happen.

Indeed, market forces should drive adoption of standards.

[awoie]

Great proposal to have the JSON-LD side thoroughly described. My own personal opinion is that JSON-LD will help greatly in the integration and after it is well adopted, this can even be used in VP Exchange to request proofs for a meaning.

On the other side, I see JSON as a gateway to implement JSON-LD vocabs. The vocab is not an easy task for governmental domains, which anyway yield many benefits for users (identity certificates, taxation..). This will take time, but if the path is there, and there is demand, then it will happen.

I really like the fact that @context is now mandatory for the base structure of VCDM, while it allows first adopters to go with JSON and take the iteration path towards evolution of unified vocabs. If everyone creates their own vocabs, it's pretty much pointless work.

Sorry, but IMO, this sounds like a tech is used for the sake of adopting a tech without giving a good reason for using the tech in the first place.

[OR13]

@awoie yes, that been our consistent approach in this working group. It's why we register extensions without any concrete usage... for example evidence and confidenceMethod.

It will be cool to see how the JSON-LD processors handle these extensions in the examples that demonstrate the value of JSON-LD processing.

I am hopeful that good examples of "framing" and "canonicalization" for credentials and presentations leveraging these extensions will make the value of JSON-LD processing clearer.

[dlongley]

@awoie,

Sorry, but IMO, this sounds like a tech is used for the sake of adopting a tech without giving a good reason for using the tech in the first place.

I agree that would be a silly thing to do.

Interestingly, I was able to understand what you wrote, without having to ask you, specifically, what each word in that sentence meant. I also understood the grammatical structure, i.e., where you placed different concepts within the sentence -- and that there was even a sentence there, again, without having to ask you, specifically, what the order meant and how it influenced what each concept meant.

I'll also note that if enough of us create similar sentences here, we will be able to combine what we wrote using these properties to create a more powerful combined set of knowledge to explain why it's useful to use a technology that allows people to make use of issuer-independent, shared vocabularies and a structure that enables both the individual understanding of atomic statements and their combination to create more useful knowledge because of their modularity. One might even consider searching the Web to find more information from others that aren't participating directly in this conversation to find even more data on the subject that can be similarly incorporated -- because how it is expressed in a common language carries these features itself.

Yes, it's true that it takes time for someone to learn a language or to adopt the words and grammatical structure of others -- people they don't even know. It's quicker and easier to come up with ways to communicate with another person that is sitting in front of you -- and pointless to do more if you never intend to talk to anyone else. But with this approach alone, most people will also never be able to talk with lots of people, even if they wanted to. If you don't adopt any rules or shared vocabularies, it won't scale beyond that. If we don't ever create a requirement that defines how people can create and reuse shared vocabularies with a common grammatical structure and instead tell everyone it's a free-for-all and to just talk to every individual to figure out what they mean, only the most popular individuals will ever be successful -- and they won't interoperate with each other. The rest of us will just tie our rudderless boats to one of them to irrevocably sort everything out for us.

This outcome should sound familiar to most people who are familiar with the identity ecosystem.

[awoie]

@awoie,

Sorry, but IMO, this sounds like a tech is used for the sake of adopting a tech without giving a good reason for using the tech in the first place.

I agree that would be a silly thing to do.

Interestingly, I was able to understand what you wrote, without having to ask you, specifically, what each word in that sentence meant. I also understood the grammatical structure, i.e., where you placed different concepts within the sentence -- and that there was even a sentence there, again, without having to ask you, specifically, what the order meant and how it influenced what each concept meant.

I'll also note that if enough of us create similar sentences here, we will be able to combine what we wrote using these properties to create a more powerful combined set of knowledge to explain why it's useful to use a technology that allows people to make use of issuer-independent, shared vocabularies and a structure that enables both the individual understanding of atomic statements and their combination to create more useful knowledge because of their modularity. One might even consider searching the Web to find more information from others that aren't participating directly in this conversation to find even more data on the subject that can be similarly incorporated -- because how it is expressed in a common language carries these features itself.

Yes, it's true that it takes time for someone to learn a language or to adopt the words and grammatical structure of others -- people they don't even know. It's quicker and easier to come up with ways to communicate with another person that is sitting in front of you -- and pointless to do more if you never intend to talk to anyone else. But with this approach alone, most people will also never be able to talk with lots of people, even if they wanted to. If you don't adopt any rules or shared vocabularies, it won't scale beyond that. If we don't ever create a requirement that defines how people can create and reuse shared vocabularies with a common grammatical structure and instead tell everyone it's a free-for-all and to just talk to every individual to figure out what they mean, only the most popular individuals will ever be successful -- and they won't interoperate with each other. The rest of us will just tie our rudderless boats to one of them to irrevocably sort everything out for us.

This outcome should sound familiar to most people who are familiar with the identity ecosystem.

@dlongley Thanks for the explanation and I really enjoyed reading it. But I think we need something more tangible for this section though. I'm not against JSON-LD, I used it and I'm still using it, contributed to vocabs etc (although I'm opinionated for which use cases to use it) but I also think that there are folks who are better suited to explain in the JSON-LD section the following:

• If people don't need JSON-LD and start with JSON, with VCs that don't have meaningful context except the VCDM 2.0 base context.
• Those people will then automatically agree and publish some spec that explains the JSON members of a credentialSubject, create JSON schemas etc. basically having their own ecosystem but without linked data. I guess that is the intention of the JSON section Add section on JSON Processing. #1202.
• If this process works for them, we need to explain why they even have a reason to change that and move to a JSON-LD / linked data model.

[OR13]

Based on the call today, I would like to see some concrete testable value of processing verifiable credentials as RDF, possibly using frame or other operations.

I don't like just saying we "get the benefits of RDF" or are "testing the RDF terms" only when using data integrity proofs.

[OR13]

Explain the value of each normative term definition, and the value the verifier gets from processing them as RDF graphs instead of plain JSON.

Specifically, explain the value of VerifiableCredentialGraph, separate graphs for proof and verifiableCredential... explain the value of RDF types, such as datetime strings or @json.

Explain the value of framing and the benefit we have enshrined by using compact form documents.

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

2.2. Document the value of processing as JSON-LD (issue vc-data-model#1227)

See github issue vc-data-model#1227.

Brent Zundel: next 1227. document the value of processing as JSON-LD; already assigned to Manu. believe this is before CR. is that accurate? could be after...not normative.

Manu Sporny: only way this becomes before CR is if it is normative..don't see us doing that.

Brent Zundel: post-CR unless objections.

Orie Steele: sort of object. still trying to understand what having a normative context & vocab means. expecting to see some substantial language in the section on the value of them being normative. have not seen that. worried that marking post-CR will mean we'll never see it.
… risk not getting the kind of language we need, and then not being able to get it after CR. comes up in the graph comment...would like to see some articulation of the value of the graph, since it is not discussed anywhere. the value of the JSON-LD section should be good and explain how normative deps are used.

Brent Zundel: Orie can you be assigned too?

Orie Steele: I'm not an RDF expert.

Brent Zundel: will label as before CR and move to next.

Manu Sporny: it's hard to write spec text around this. can take a shot. Orie, what you're asking for is [metaphor about rocks].
… if you could write something that would be helpful.
… bulleted list of items you want in that section would be useful. would also need to talk about normative language you would like to see in there. if we don't have that, then it is a post-CR thing.

[iherman]

The issue was discussed in a meeting on 2023-08-30

• no resolutions were taken

View the transcript

4.5. Document the value of processing as JSON-LD (issue vc-data-model#1227)

See github issue vc-data-model#1227.

Brent Zundel: value of processing JSON-LD.

Manu Sporny: you can mark it ready for PR. we are working on text for it activly.

[msporny]

PR #1270 has been raised to address this issue. This issue will be closed once PR #1270 is merged.

[msporny]

PR #1270 has failed to achieve consensus and is being closed. Marking this issue as pending close as it is unlikely the WG will be able to achieve consensus on a PR to address this issue.