Remove termsOfUse from v2 context

[OR13]

Addresses #1090

---

Preview | Diff

[msporny]

-1 for the following reasons:

• The PR title is not accurate, it removes refreshService as well as termsOfUse.
• This term has already been used as an extension point in the VC Specifications Directory.
• It only impacts JSON-LD implementations (and the cost is a handful of bytes for a context that is permanently cached and never downloaded).
• There is active interest in this extension point (as evidenced by TRAIN work in the EU).

[iherman]

-1

This seems to be a rushed PR on an unfinished discussion yesterday, namely whether references to an "experimental" (whatever name we will use) term should be removed from the @context file or not. In my view, unless the term is fully removed from all our documents, this should not be done.

As I said on the call, as long as the term has a URL in our vocabulary (https://www.w3.org/2018/credentials#termsOfUse in this case) the term should remain in the @context file. And we did agree on the call (although there were no formal resolution) that if we keep a term in the VCDM (regardless whether it is a "experimental" or a bona fide standard term) then we also keep it in the vocabulary with the right URL.

The @context file does not define anything whatsoever. The term in question is defined in the VCDM specification and the VCDM vocabulary document. In the sense of the specification, the @context file is merely a helpful tool for JSON-LD implementers to make it sure that when they use the JSON key termOfUse, they indeed use the one the WG has agreed upon. Fundamentally, that is al it does. If the item is removed from the @context, by virtue of the @vocab that we introduced in @context, the term will instead be turned into https://www.w3.org/ns/credentials/issuer-dependent#termOfuse, which is not what we would want.

[OR13]

Fundamentally, that is al it does. If the item is removed from the @context, by virtue of the @vocab that we introduced in @context, the term will instead be turned into https://www.w3.org/ns/credentials/issuer-dependent#termOfuse, which is not what we would want.

This is what I would expect for a term that the working group has not agreed to use, but for which an issuer has found value.

I stated this at the end of the call.

If the working group has agreed to this term, as a normative requirement, it should not be reserved, and it should be defined in the TR AND in the JSON-LD context.

We should avoid bundling non normative stuff into the JSON-LD context, since they are cached, they can be split by normative and non normative easily, and then implementers can more easily signal their intention to use experimental extensions.

[dlongley]

@OR13,

Fundamentally, that is al it does. If the item is removed from the @context, by virtue of the @vocab that we introduced in @context, the term will instead be turned into https://www.w3.org/ns/credentials/issuer-dependent#termOfuse, which is not what we would want.

This is what I would expect for a term that the working group has not agreed to use, but for which an issuer has found value.

From my perspective, this misses the point and distinction introduced by the prospective ("reserved") terms table. The terms we put in that table are specifically called out as not being "issuer-defined", but rather prospective terms that will be defined by the WG in the future (or by a future WG) ... and therefore independent of any issuer. They map to URLs in the WG-defined vocabulary.

[David-Chadwick]

-1 to this request

[longpd]

-1 to this request, as well. I concur with @dlongley, @iherman and @msporny. @context files are implementation tools to make easier and more clear what is being referenced as defined by the VCWG.

[TallTed]

-1 from me, too.</aol>

[decentralgabe]

if it were just removing termsOfUse and not also refreshService I'd approve

[brentzundel]

There does not seem to be a path toward consensus that would result in merging this PR.
I am adding the pending-close label and will close in 1 week if consensus still seems unlikely.

[OR13]

I thought we had agreement, that we would be reserving this URL and term name, and not defining it or using it in the v2 spec?

[msporny]

I thought we had agreement, that we would be reserving this URL and term name, and not defining it or using it in the v2 spec?

Removing both declarations from the v2 context (what this PR does) is something that we did not have consensus on, and are unlikely to get consensus on it. It's been a week since being marked pending close. Closing.