Add @vocab to v2 context

[OR13]

Addresses: #953

[mprorock]

This is an awesome path - i particularly like the private-claim approach for labeling

[msporny]

In general, supportive of the PR as long as the following change is made (see @iherman and @dlongley's comments as to why):

The @vocab URL should point to something that doesn't confuse these class of terms with the terms in the well defined vocabulary, so something like https://www.w3.org/ns/credentials/WORD# (in the case where we get rid of 2018). This will make it easy to have a separate page that caters to the intent of setting a global base vocabulary. The word we use for WORD will need to be debated, which was entirely predictable, given that some want to use @vocab to elicit something that's "undefined" (which is true for some definition of 'undefined'), while others want to use it for "private claims" (which is a misleading 'cause it can be used for public, but negotiated out of band, claims), while others want to use it for "issuer-dependent-vocabulary" (which is more accurate, but a mouthful).

[iherman]

The issue was discussed in a meeting on 2023-01-11

• no resolutions were taken

View the transcript

2.4. Add @vocab to v2 context (pr vc-data-model#1001)

See github pull request vc-data-model#1001.

Manu Sporny: Next PR is 1001. It's about add vocabulary. We need more reviewers on this..

[vongohren]

Quick question, adding this vocab, technically means that all VCs will pass JSON-LD validation? So if you do a mistake it still passes and you have to look for private-claim to verify what is unreferenced? Just asking a stupid questions after trying to follow the issue

[msporny]

Quick question, adding this vocab, technically means that all VCs will pass JSON-LD validation?

Yes, correct. Now, in order to detect errors, you'll have to look for terms that map to the "undefined" namespace.

So if you do a mistake it still passes and you have to look for private-claim to verify what is unreferenced?

Yep, you got it.

[OR13]

@msporny please re-review.

[vongohren]

Quick question, adding this vocab, technically means that all VCs will pass JSON-LD validation?

Yes, correct. Now, in order to detect errors, you'll have to look for terms that map to the "undefined" namespace.

So if you do a mistake it still passes and you have to look for private-claim to verify what is unreferenced?

Yep, you got it.

Cool cool. It sounds scary but I assume as a compromise all json ld referencers will add a warning? Or is it up to the verifiers and issuers to handle this?

[iherman]

This works for me.

[iherman]

Well... a minor point, however: I am not sure if we agreed on whether the URL for the VCDM vocabulary (not the context!) will be relocated to .../ns/credentials/. At this moment, it is still located in .../2018/.... We may want to wait merging this PR until that issue is solved. If, however, we decide not to relocate, then the URL for @vocab should be in .../2018/..., too

[OR13]

@iherman yes... I discussed this with @msporny... I had same thought... This was the proposal that came from that... If this discussion balloons because of that choice, I suggest we revert to 2018.

[msporny]

Cool cool. It sounds scary but I assume as a compromise all json ld referencers will add a warning?

Nope, that is unlikely to happen on any sort of short term time frame. We're going to have to go back to the JSON-LD implementer community and see if they're interested in adding such a feature.

Or is it up to the verifiers and issuers to handle this?

Undefined. :)

This is why some of us were warning that putting @vocab in the base context was problematic. It basically turns off error processing. Some view turning off error processing as a good thing, leading to an easier adoption path for developers. Others view turning off error processing as silencing errors that could have catastrophic consequences for some use cases (like banking, finance, healthcare, etc.).

I know that Digital Bazaar is going to have to invest in adding a feature to our JSON-LD processors that will have a callback when certain types of triples are generated now (such as those that are in the "undefined namespace") in order to be able to throw linting warnings to developers that care about the use of @vocab.

Make no mistake, this is a "hold your nose" compromise for some of us. :)

[iherman]

The issue was discussed in a meeting on 2023-01-18

• no resolutions were taken

View the transcript

2.2. Add @vocab to v2 context (pr vc-data-model#1001)

See github pull request vc-data-model#1001.

Manu Sporny: next item is remove zkp, we will address in special topic call later..
… next is PR 1001, it covers the @vocab URL, and provides terms for anything that are related to the issuer..
… we intend to provide better developer and user experience by for folks built on this feature.
… there are no objections, we intend to merge by end of day.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.