Breaking changes to IRIs in JSON-LD Context

[OR13]

TLDR:

"@id": "https://www.w3.org/2018/credentials#VerifiableCredential",

To:

"@id": "https://www.w3.org/ns/credentials#VerifiableCredential",

[TallTed]

Where's the unread TL that's summarized by the above TLDR?

[Sakurann]

Where's the unread TL that's summarized by the above TLDR?

The discussion we had in the VC WG call I think: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-01-11-vcwg#section3-6

[msporny]

PROPOSAL: The VCWG will not break existing vocabulary URLs that were approved in the v1.0 and v1.1 work.

I'm marking this as pending close, waiting for objections to prevent that from happening.

[OR13]

@msporny can you modify your proposal to cover how we will handle "new terms", just so we can see how this will interact with new terms?

for example:

"@id": "https://www.w3.org/2018/credentials#VerifiableCredential"
...
"@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#",

I assume we will see both of these bases in context v2, and I assume we will NOT break any existing term definitions.

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

1.11. Breaking changes to IRIs in JSON-LD Context (issue vc-data-model#1007)

See github issue vc-data-model#1007.

Kristina Yasuda: By Orie, about breaking changes in IRIs..

Manu Sporny: I'm going to try to close this. The VCWG will not break existing vocabularies. I will mark this issue "pending close", and people who want breaking changes can object and try to keep it open..

Kristina Yasuda: Orie do you want to speak to this?.

Orie Steele: I will leave comments on the issue..

[msporny]

@msporny can you modify your proposal to cover how we will handle "new terms", just so we can see how this will interact with new terms?

I would expect that we could get consensus around the following:

PROPOSAL 2: New terms created by the VCWG can use any base vocabulary URL that is under the control of VCWG and will be considered on a case-by-case basis.

While that doesn't directly answer the question, I imagine that "picking one" will not lead to consensus. If we had to pick one, at this point, I'd suggest we just use https://www.w3.org/2018/credentials# ('cause only developers down in the weeds are going to care, and those folks are very far down the priority of constituencies list)... and I expect others in the group might have a strong opinion the other way. :)

I assume we will see both of these bases in context v2, and I assume we will NOT break any existing term definitions.

Yes, that's my assumption as well.

[iherman]

On

PROPOSAL 2: New terms created by the VCWG can use any base vocabulary URL that is under the control of VCWG and will be considered on a case-by-case basis.

While that doesn't directly answer the question, I imagine that "picking one" will not lead to consensus. If we had to pick one, at this point, I'd suggest we just use https://www.w3.org/2018/credentials# ('cause only developers down in the weeds are going to care, and those folks are very far down the priority of constituencies list)... and I expect others in the group might have a strong opinion the other way. :)

I would actually make this somehow stronger. Any term that is defined as integral part of the VCDM MUST be added to the same vocabulary, ie, https://www.w3.org/2018/credentials#. In other words the two URL-s that are VCDM related are:

"@id": "https://www.w3.org/2018/credentials#…"

and

"@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#"

Obviously, other terms may be reused from other vocabularies, whether they are well established, like DCMI or Schema.org terms, or under development in this WG (like the security vocabulary) or elsewhere. But we are talking about the terms that are defined as part of the VCDM spec.

[OR13]

Ok, so we will be adding terms added in 2023 to a URL that says 2018.
But only for terms that are part of the core spec?

[iherman]

Ok, so we will be adding terms added in 2023 to a URL that says 2018.

I know this is silly, but we have to pay the price for the mistake (imho) of having put that vocabulary in date space back then.

(We are in good company... the RDF namespace is http://www.w3.org/1999/02/22-rdf-syntax-ns# which even gives the day when it was created, although new terms have been added since. Everybody knows it was a mistake, but we all have learned to live with it...)

But only for terms that are part of the core spec?

Yep.

[OR13]

The good news is that JSON processors who never convert to RDF will never see this mistake.

I am closing this issue, as there is no action here.