Avoiding confusion by renaming 'credentialSubject'

[RieksJ]

In section 4.4, the term 'credentialSubject' is defined, suggesting a relation between the credential in which it is included and a 'Subject', i.e. an entity about which claims are made. However, the credentialSubject section contains a list of claims, rather than a (or more) subject(s).

This issue calls for renaming 'credentialSubject', and provides the following suggestions

• 'credentialSubjectProperties'
• 'claims'

[brentzundel]

+1 to claims

[awoie]

+1 to claims

[ken-ebert]

+1 to claims

[jandrieu]

+1 to claims

[David-Chadwick]

We have been round this one many times, and the reason it was changed from claims is that the ID is not the iD of the claim, but the ID of the subject. So the object needs to have subject somewhere in its name.

[brentzundel]

@David-Chadwick, I agree that it makes sense to those of in the group to call it the credentialSubject for the reasons you mentioned.
This doesn't change the fact that it is confusing for others. We say that a verifiable credential contains claims, then show a data model that (for valid, yet pedantic reasons) has a credentialSubject property. We then have to explain that that's where claims should go, and then explain why the property is not just called "claims," since that is what a verifiable credential supposedly contains.

Rather than requiring this educational moment every time someone new looks at the data model, I support the proposal to change credentialSubject back to claims.

[jandrieu]

I think there was also confusion about the embedded graph container, making the RDF subject of the claims confusing. We have examples in the focal use cases where there are multiple subjects, for example in a birth certificate and marriage certificate.

"CredentialSubject" strongly suggests that there is always single subject of the credential, but that's demonstrably untrue.

@dlongley could you provide an example of how an issuer would construct a VC with multiple subjects?

I scanned the current spec, but only found examples such as the following:

...
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    }
...

Am I correct that simply replacing that single object with an array works?

  "credentialSubject": [{
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    },{
    "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
    "parent": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "type": "Mother"
    }]

If that's correct, I believe @David-Chadwick's issue isn't with CredentialSubject but with the id.

The example says, in effect, that the subject of the first claim is the mother of the subject of the second claim.

In this case, I think the best we can do is explain clearly that "id" is the "id" of the subject of just the each claim. That's something we need to clarify, but my understanding is that the way JSON-LD works the "id" field is necessary. Or is it possible to change the "id" field to "claimSubject"? That's the semantic meaning in this situation. Can we make it explicit?

In any case, when you see the multi-subject "CredentialSubject", it doesn't make sense.

[David-Chadwick]

The way out of this dilemma is to have a claims object that contains within it one or more credentialSubject objects. Then it is clear that the VC contains claims, and that the ID is that of the subject. Eg.

"claims": [
 "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    },
"credentialSubject": {
    "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
    "parent": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "type": "Mother"
    }
]
...

[jandrieu]

That's not bad, except I believe the "credentialSubject" is actually a "claimSubject" in your example.

[talltree]

I like it too. And with that context, wouldn't just "Subject" work as the name?

…

On Wed, Apr 3, 2019 at 7:17 AM Joe Andrieu ***@***.***> wrote: That's not bad, except I believe the "credentialSubject" is actually a "claimSubject" in your example. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTbh3PPL8HF2VN9ODFBEYubXA5nBwks5vdLgBgaJpZM4cNFRu> .

[jandrieu]

Maybe. I think folks get wrapped around the singular subject, thinking a credential can only have one subject. ClaimSubject focuses it nicely on this particular claim, gently inviting credentials that have claims about many subjects.

[msporny]

I will note that the conversation in this issue is all over the place and is pretty classic bike shedding during the Candidate Recommendation phase (typically, a terrible, horrible time to bike shed core properties in the specification since implementers are already busy implementing using the properties that are currently being bikeshedded in this issue).

-1 to anything plural (claims, subjects, properties, etc.). schema.org made that mistake years ago and has been busy playing whack-a-mole to remove all the plural properties. The same goes for the Web Payments specification. We have over a decade of experience now naming properties that will go back-and-forth between JSON and RDF and the best practice is to NOT use plural form.

-1 to claim (and I say this as the person that initially put that in the specification). You are expressing "one or more credential subjects". The language in the spec may lead people to a different conclusion, and if it does, we should fix that specification text (not change the property to something that it's not).

I also note that the WG has many more things to worry about at present than bike shedding a name. Can we please just drop this issue and focus on things that are a better use of the WGs time? I'm concerned that this issue is going to consume a lot of time that should be spent doing things like getting the VC extension registry up and running, working on use case finalization, etc.

@RieksJ -- perhaps there is some non-normative text that you would like added to the specification to explain why the "credentialSubject" property is named what it is named?

[RieksJ]

I appreciate that there is a lot to do. However, I don't consider heavy workloads as a valid argument for deciding to skip issues in a standardization process. I would support it as an argument to postpone the transition to a next phase, because standards should be solid. And in particular, discussions about what might seem to be details should be done carefully, because that's where the devils tend to be, and in my experience as expert in ISO SC27/JTC1, fixing standards is much harder once they're out there.

Note that this is not an argument to discuss every detail - relevance of the discussion must be shown first. The relevance of this issue is to prevent confusion and misinterpretation by readers (standards should be unambigous and clear). The term 'credentialSubject' suggests that there is a relation between the credential and a single subject (which isn't there). But even if we say that this standard uses singulars, then 'credentialSubject' still has the word 'Subject', and that doesn't cover its payload (which is a set of Claims). It is like having a sign on the door of a restroom that says 'Chair'.

To me, it is relevant that standards do not have these kinds of things in them. But if there is a consensus that preventing such confusion is irrelevant, then I have no problems with closing this issue, because that's how standardization works.

@msporny: I don't think it is up to me to elaborate on why 'credentialSubject' is named as it is, because I did not invent that name (and I wouldn't have named it that in the first place for the same reasons I created this issue).

[dlongley]

@RieksJ,

Using a relationship named credentialSubject makes sense in the data model, particularly if you think of the data as a graph, which is what we're modeling.

A credential is a node in this graph. If you want to represent something about this node, you create a link emanating out from the credential node that connects to another node in the graph. For example, if you want to identify the issuer of the credential, you can create a link named issuer and use it to connect the credential node to another node that represents the issuer. If you want to say that a credential is about a subject, you can link the credential node with a link called credentialSubject that connects to the subject node. If you want to say that the credential is about yet another subject, you create yet another link called credentialSubject and connect that to that other subject.

You can see from this why using plural names for links doesn't make much sense. The links identify the relationship between two nodes in a graph; if you want to say one node has the same kind of relationship with two other nodes, you add two links of the same name to the graph, each connecting to one of the other nodes.

Now, if you want to say things about any one of those subjects, you repeat this process -- you link the subject node you want to say something about to another node through another relationship. For example, you could create a link called alumniOf that connects the subject node to a node that represents a literal string value of Example University.

In the JSON and JSON-LD syntax, links are represented as JSON keys, where the JSON key id is a special key that is used as an identifier for a node. Nodes are represented as JSON objects or, if a node represents a literal value, it can be a string, number, boolean, etc. Other syntaxes may do something different while still being compliant with the data model.

At a high level, the entire graph is therefore comprised of sentences that include a "subject" (a node), a "property" (a link), and an "object" (another node/literal value). These sentences are the "claims" -- and in our model they are understood to have been made by the entity identified as the "issuer".

We have a picture of a graph showing how this works in the data model:

[RieksJ]

Section 4.4 Credential Subject says "This specification defines a credentialSubject property for the expression of claims about one or more subjects". Since JSON-LD does not allow duplicate keys, then what does a credential look like (in JSON-LD) that has claims (or better: JSON-LD graphs) about two different subjects? And might the figure need clarification so that it better shows how multiple claims on different subjects are done?

[dlongley]

@RieksJ,

Since JSON-LD does not allow duplicate keys, then what does a credential look like (in JSON-LD) that has claims (or better: JSON-LD graphs) about two different subjects?

Instead of using a single object for the value of credentialSubject an array of objects is used:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "credentialSubject": [{
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe"
  }, {
    "id": "did:example:3d5c623bf63156cb1",
    "name": "John Doe"
  }],
  "proof": { ... }
}

And might the figure need clarification so that it better shows how multiple claims on different subjects are done?

+1. If you could propose some concrete text that helps clarify things for you we'll be able to pull it in much more quickly. And if you or someone else has the time to add another picture showing multiple credentialSubject links that would also be great.

[RieksJ]

W.r.t. the figure: I've tried to do some quick stuff with svg, but I've trouble getting it done. I propose the following changes (decreasing importance):

1. draw a box around the yellow boxes; this box is similar to that of 'credential graph' and 'proof graph' and could be named 'claims'.
2. draw this box several times at a slightly different place, thus suggesting that multiple such claims can be referended
3. add some more yellow boxes such that it becomes clear that there is a linked data graph here.

W.r.t. texts: the comments above by various people indicate that the texts that describe what a credential, a subject, a claim, etc. is, is far from clear, even for people that are consistent contributers to the text. While the issue I raised was just a part of this discussion, it seems to me that a decision is called for to determine whether to revise the text so as to address these issues, or leave it as it is. While it is my preference to do the first, I don't make these decisions.

[burnburn]

Decision on VCWG call 7 May 2019:
RESOLUTION: The Working Group has discussed issue #480 and is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase. The Working Group is interested in exploring non-normative resolutions to the issue. The WG would like to defer the issue so it can be considered when work continues beyond VC 1.0.

[kdenhartog]

We discussed this on the maintainence working group call and believe that this PR can be closed due to the impact on the number of implementations already done today. If the author believes this should still be addressed it can be handled in V2 and they can reopen it.

[iherman]

The issue was discussed in a meeting on 2021-08-11

• no resolutions were taken

View the transcript

4.6. Avoiding confusion by renaming 'credentialSubject' (issue vc-data-model#480)

See github issue #480.

Wayne Chang: this would add a huge breaking change, renaming a major component

Manu Sporny: +1 this would be a huge breaking change.

Dave Longley: +1 to close

Manu Sporny: +1 to closing

Wayne Chang: probably good to close, but we'd need to see broad support for changes like this in the new working group to re-open

[RieksJ]

I am disappointed by the way this issue has been treated and has come to a close, as it might have been properly dealt with around the time it was raised. Instead, it has been lying around for over two years, thereby implicitly instructing all implementations to follow the contested practice. Allowing this issue to remain unaddressed caused it to become a 'huge breaking change', and continues to do so up to at least v2. It is like instructing people to litter a place and then refuse to participate in cleaning it up, suggesting that you can have another shot at it when you build a new place (v2). I consider this a bad practice for a standardization group.

[msporny]

I am disappointed by the way this issue has been treated and has come to a close, as it might have been properly dealt with around the time it was raised.

@RieksJ, while I can understand your frustration, the reality is that the group did discuss the issue at depth: namely, in issue #207

Then, when you raised this issue (during the Candidate Recommendation phase), the group did debate it again and came to the conclusion that it did not want to make the change you were suggesting: #480 (comment)

Since then, there has been hardly any discussion on the issue, which signals to the group that it has not been a concern for people building solutions using Verifiable Credentials.

While you are free to be disappointed with the outcome, the concepts that you raised in the issue did get very broad discussion in the group and the group did come to consensus on the path forward.

Fundamentally, the flaw with the argument in this issue is this: "the credentialSubject section contains a list of claims, rather than a (or more) subject(s)."

The credentialSubject section does, in fact, provide an associated list of credential subjects (that's why the name was picked), identified explicitly by credentialSubject.id or implicitly by an auto-generated identifier (blank node identifier). This is why the credentialSubject property was where the group ended up. We then hang claims off of each credential subject identifier. I personally would've preferred something else, but that's neither here nor there... credentialSubject is what achieved group consensus.

[mwherman2000]

RE: ...or implicitly by an auto-generated identifier (blank node identifier).

@msporny Where is this implied or, better, stated?

[mwherman2000]

@RieksJ let me amplify 2 concepts from your post: standardization effort and hallucination ...

It is a hallucination that the effort to produce the VC Data Model Specification document is an effort to produce a standards document.

This is the light that was turned on for me last night by @brentzundel, @msporny, and others. There is a miles wide difference between a standards document and a W3C consensus-based data model specification for verifiable credentials. With this characterization, I can appreciate and accept the document in its current form (i.e. the current version 1 W3C consensus-based data model specification). I (and I believe others) should not accept the current document as representing any form of standard.

I've proposed the following new document title to reflect this clarification: #791 : W3C Consensus-based Data Model Specification for Verifiable Credentials

The former takes on the air of being a Standards document - but the current version 1 document does not reach that bar. The version 1 document lacks cohesiveness, connectedness and reliability - which makes it unattractive and unacceptable as a "standards" document.

p.s. Sounds like the W3C community consensus process is very similar to the process the US Congress uses: https://en.wikipedia.org/wiki/Pork_barrel (not sure what made me think of this but the metaphor seems accurate):

The term pork barrel politics usually refers to spending which is intended to benefit constituents of a politician in return for their political support, either in the form of campaign contributions or votes.

[msporny]

I (and I believe others) should not accept the current document as representing any form of standard.

What standards do you believe should be accepted? What standards process do you find acceptable? Can you provide concrete examples?

[msporny]

@RieksJ wrote:

when making any decision regarding some issue, document that in the issue (e.g. refer to the meeting minutes, provide the argument/conclusion of the discussion);

We did this here: #480 (comment)

when closing some issue, make sure that the argument(s) for doing so actually contribute to (the quality of) the standard.

It is believed that this was done here: #480 (comment). By changing the name at this point, it would be a big breaking change w/o any upside. In addition, I further explained why it contributes to the quality of the standard here: #480 (comment)

realize that standardization is a time consuming process. We are with many, we want consensus (this takes time), and several people have more important things to do (so they need time as well if they want to contribute)

I believe this is broadly understood in the WG. There are a fair number in the group that have decades of experience in the space, have participated in many standardization activities, and understand this. It is also repeated to the new members in the group about how much time it takes to get through the process.

So, I believe the WG is already operating with your suggestions as a standard practice. That is not to say that we can't improve, of course that's possible and the WG strives to do that. However, in order to do that, you need to give us suggestions that are outside of our standard practice.

If I can try and summarize what I think the real issue is: It seems like you think your issue was deferred due to esoteric W3C Process ("We're in Candidate Recommendation, we can't make that change now... let's defer the issue so that we'll never be able to make the change.")... and I can understand why, based on earlier communication, that you're coming away with that impression. IMHO, the reality is that it was a misguided idea from the beginning and rather than tell you that directly, the WG attempted to soften the blow by using process rationale rather than saying "That's a misguided idea." That's the mistake that I think the WG made.

The issue is re-opened, the WG will discuss it, I expect it to come back with a stronger position and a concrete resolution this time based on the conversation happening in this issue.

@RieksJ, I hope that helps in some way.

[msporny]

@mwherman2000 wrote:

The term pork barrel politics usually refers to spending which is intended to benefit constituents of a politician in return for their political support, either in the form of campaign contributions or votes.

Please refrain from casting these sorts of aspersions on the group. Everyone that I know of in the group is acting in good faith, engaging publicly and transparently, the debates use logic and sound rationale, decisions are made by consensus as defined here: https://www.w3.org/2020/Process-20200915/#Consensus .

In other words, it's different in significant ways from pork barrel politics... and that you continue to repeatedly cast these aspersions on the group is most likely harming some of the good input that you do have.

[mwherman2000]

What standards do you believe should be accepted? What standards process do you find acceptable? Can you provide concrete examples?

IMO, this is a redherring/diversionary question. The issues are with the current version of the spec by itself.

@msporny you yourself have described a number of places in the current specification that don't hang together, are not well connected ....that the specification lacks cohesion: the conceptual model diagrams, the fact that credentialSubject id doesn't have to be present, the fact that JSON-LD is thrown into the specification but not integrated throughout.

The current specification, based on my reading of your previous comments and the specification itself, IMO sounds, looks, and reads like a #porkbarrel ...a #bunchofstuff.

[mwherman2000]

By changing the name at this point, it would be a big breaking change w/o any upside.

Please cease to use this as an excuse @msporny. It is/was a draft specification. If some early adopters/innovators/first movers (reference: model 1 in https://hyperonomy.com/2019/10/16/technology-adoption-models/) chose to bet their resources/energies/companies on a draft specification, this should not ever impact that is considered a needed change.

Also, by making this types of assertions, it amounts to #cliquespeak ...you're trying to stymie a conversation for what I consider is an unjustifiable reason.

Similarly the following comment in #790 (comment) amounts to #cliquespeak but putting down the chances of new input being accepted before it's fully presented. You're in effect signaling to the community to disregard the suggestions before they's presented. @msporny please stop engaging in #cliquespeak (reference: https://hyperonomy.com/2019/04/09/clique-speak/)

Remember that you have at least 60+ people (number of people/implementers in the WG) you're going to need to convince on that new direction. More power to you if you figure out something simpler that achieves consensus.

[mwherman2000]

Please refrain from casting these sorts of aspersions on the group. Everyone that I know of in the group is acting in good faith, engaging publicly and transparently, the debates use logic and sound rationale, decisions are made by consensus as defined here: https://www.w3.org/2020/Process-20200915/#Consensus .
In other words, it's different in significant ways from pork barrel politics... and that you continue to repeatedly cast these aspersions on the group is most likely harming some of the good input that you do have.

Your comment IMO is another diversion.

The US Congress works in the same ways with people with the same good intentions. What I am specifically referring to is what the end work product looks like (a bill in the Senate, the VC 1.0 specification in the immediate context).

[mwherman2000]

Going farming: https://www.youtube.com/watch?v=NfP0cOaYg0U

[andrewhughes3000]

I'd like to know of specification development groups who are not in "cliquespeak" mode and that have produced exemplary standards documents. I would like to learn from them - because it's not easy to establish such an environment and I'd like to take those lessons into other fora.

On Sat, Aug 14, 2021 at 6:36 AM Manu Sporny ***@***.***> wrote: I (and I believe others) should not accept the current document as representing any form of *standard.* What standards do you believe should be accepted? Can you provide concrete examples? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#480 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETAZ7BDNGNKN6QOHOEH6GTT4ZWNTANCNFSM4HBUKRXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

-- Andrew Hughes CISM CISSP In Turn Information Management Consulting o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave,, Victoria, BC V8Y 1W9 ***@***.*** https://www.linkedin.com/in/andrew-hughes-682058a Digital Identity | International Standards | Information Security

[dlongley]

At certain point in the standardization process a spec must be considered "normatively complete" or else it will never finish (never become a standard). This is really just axiomatic. The standards process in that way is not unlike any other consensus algorithm; you have to accept that new input will eventually be refused in order to produce a stable output.

Understandably, this is a difficult period during the process as there's always something new or different that someone would like to tweak. This is one reason why the deadline by which this restriction gets triggered is largely independently set to some number of years/months from the start date of a WG. There is also always some other person who exists on the planet and who is not yet part of the WG who could potentially show up around this deadline with new input. That doesn't mean that their input is not valuable or that a clique has been formed specifically to exclude them on the basis that they are not part of the "in crowd".

A number of people that have gone through the standardization process before may try to apply their experience, through language, to help ensure that participant input is maximized in a way that will reach consensus by the deadline. The goal is not to exclude anyone, rather, it is to ensure that the deadline is met whilst maximizing input. That maximum implies a ceiling; it necessarily means some input will not make it. That's just how time works. This is an alternative explanation for the motives of people who have been described as engaging in "#cliquespeak".

Whether or not we accept the reality that the work must end at some point -- and that we get whatever the WG has been able to reach consensus on in that period of time -- doesn't change the fact that it is a reality of any terminating process.

What I think one should want from a WG is output that both instructs implementers on how to build interoperable solutions for the use cases the WG was chartered to solve -- and evidence that at least two independent implementers were able to follow those instructions to produce said solutions. Often, the easier it is to follow those instructions, the better, but we should keep in mind that ultimately the priority of constituencies is end users first, then implementers, then spec authors. And, with end users being the most important here, it is better to ship something that starts solving their use cases in an interoperable way (giving them choice), than to stall indefinitely. Specs also need to reflect reality, and by that I mean that if there are no implementers willing to implement a particular feature or unwilling to implement it in a particular way, then it doesn't matter how beautiful the spec is -- the use case doesn't get solved.

No spec built on consensus will ever look exactly the way any particular person wants it to look, because no one controls anyone else. Accepting other people's input and allowing it to color the output is the definition of consensus -- and the very opposite of creating a "clique" whereby everything goes exactly according to the group's shared desires. One should expect that a specification that was built by consensus (as opposed to being built by a clique) will show some of those signs.

Marshaling all of these concerns to produce a standard is hard. I'm very appreciative of the work that was done by the editors and chairs in the VCWG to make it happen.

[RieksJ]

@msporny I guess the TL;DR of what I am asking is that when a decision is being made about the resolution of an issue,

• be unambiguously clear that this is the case and also what the final argument(s)/motivation are for that.
• record both the decision and (a reference to) the argument/motivation in a single comment to that issue.

Apart from this, it would help if every comment in an issue would be relatable to the issue as stated in its first/original comment. I see lots of (good and other) discussions in issues that have drifted away from the original topic. It would be nice if there were a way to move such comments into separate issues with a more appropriate title.

[TallTed]

[@RieksJ] It would be nice if there were a way to move such comments into separate issues with a more appropriate title.

1. Click on the three-dots at upper-right of the comment you want to move.
2. Choose "Reference in new issue".
3. Follow your nose through the Github UI to start that new issue.
4. Presuming that none of its content is relevant to the issue on which it was originally posted, return to the comment you started with in (1) above.
5. Click on the three-dots at upper-right of the comment once more.
6. Choose "Hide".
7. Follow your nose through the Github UI to choose the appropriate reason for hiding it.
8. Repeat as necessary.

This doesn't solve the issue of sub-threads where multiple comments should be moved, but it's a good start. Also, it is entirely possible to manually construct a comment-of-quotations, and to then hide all those quoted/moved comments in the original Issue/PR for which they are off-topic.

[talltree]

Very valuable guidance, Ted. Thanks for highlighting a practical route to better "issue topic management". =Drummond

…

On Mon, Aug 16, 2021 at 1:20 PM Ted Thibodeau Jr ***@***.***> wrote: ***@***.*** <https://github.com/RieksJ>] It would be nice if there were a way to move such comments into separate issues with a more appropriate title. 1. Click on the three-dots at upper-right of the comment you want to move. 2. Choose "Reference in new issue". 3. Follow your nose through the Github UI to start that new issue. 4. Presuming that none of its content is relevant to the issue on which it was originally posted, return to the comment you started with in (1) above. 5. Click on the three-dots at upper-right of the comment once more. 6. Choose "Hide". 7. Follow your nose through the Github UI to choose the appropriate reason for hiding it. 8. Repeat as necessary. This doesn't solve the issue of sub-threads where multiple comments should be moved, but it's a good start. Also, it is entirely possible to manually construct a comment-of-quotations, and to then hide all those quoted/moved comments in the original Issue/PR for which they are off-topic. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#480 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZOITPCWHN6WEHMPULMBSDT5FXKJANCNFSM4HBUKRXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[TallTed]

[@mwherman2000] #cliquespeak (reference: https://hyperonomy.com/2019/04/09/clique-speak/)

Your constant references to LONG external posts, authored and curated by you, on your website, do little to support your arguments here or elsewhere, and take on their own flavor of "#cliquespeak", because that's your term, not actively used by anyone else (so far as I've noticed, anyway, which suggests it's rare at best). The part where such external posts are neither preserved nor preservable as part of the conversation at hand is also problematic -- even if you're pledging to do such perpetual preservation on/of that external site.

[@mwherman2000] It is/was a draft specification.

No. It was, but then it went through a few review periods, as prescribed by the W3 Process, and it emerged as a Technical Recommendation. No "draft" about it at that point, though it was indeed a 1.0, and I think everyone who participated in producing it expected there to be subsequent revisions to 1.1 or 2.0 or whatever.

[@mwherman2000] Your comment IMO is another diversion.

This comment impugns @msporny's motives and actions in a manner which I find insulting at best, and, collected with a number of your other comments, in significant violation of the Positive Work Environment at W3C: Code of Ethics and Professional Conduct (CEPC), to which you agreed to abide when you joined either the W3C Membership writ large (including any participation as an Invited Expert) or any Community Group (such as the CCG).

I do not believe I am the first to throw this flag on one or more of your comments, though I may be the first to explicitly point to the CEPC. Please take this as a sign that your comments are not coming across in the spirit in which I hope they are meant, and therefore please take some action to at least modify the way you're expressing yourself.

[@mwherman2000] Going farming: https://www.youtube.com/watch?v=NfP0cOaYg0U

This comment is more broadly insulting, IMNSHO, not least nor only because it is a standalone comment, purely noise, in this thread. "See how superior my office and view are to yours?" I suggest and request that you refrain from repeating this comment, even when it's one line of many in an otherwise contextually relevant comment, and consider hiding it above.

[mwherman2000]

@TallTed The diagnosis that people have experienced/observed cliquey did not originate with me. Rather cliquey appears in the Credentials Community Group 2018 End of Year Survey Results - Conducted, Analyzed & Authored by Heather Vescent & Karn Verma. Here's a original version with the specific highlighted in red (by me): https://hyperonomy.files.wordpress.com/2019/04/final_-ccg-2018-eoy-survey-results-annotated.pdf

The 10 Real-Life Examples of #Cliquespeak are, in fact, real-life examples. I have the original email messages. They are there as an educational resource/examples.

[RieksJ]

@TallTed tnx for the suggestion. I see that the part on creating a new issue works. That's a start. However, the part of hiding the originating comment does not (I experimented with your comment, but it failed...). But we could ask others to comment on a new thread and that just might work.

[TallTed]

[@RieksJ] However, the part of hiding the originating comment does not

This might require specific permissions on the specific repo, e.g., a member of CODEOWNERS might need to do it, for comments by users other than the person doing the hiding. I know I can hide my own past comments. (I don't want to hide anything that ought not be hidden, so I won't be experimenting with anyone else's comments here.)

[TallTed]

@mwherman2000 — You appear to have focused on the first and ultimately least important section of my comment above, and ignored the rest. Please revisit, and reconsider your next comments, in this and other threads, especially but not only in light of the CEPC.

[mwherman2000]

@TallTed No one has an obligation to respond to anyone's comments ...in whole or in part. Yes, I responded to the parts that I felt were important (and what I felt were the most important to others from my perspective).

(I was also time-constrained this morning because I had to be back combining by 9am because the forecast was for rain at noon ...the rain started at 1pm and we eventually had to shutdown for the day.)

@TallTed you're becoming a bit overbearing IMO.

[msporny]

@TallTed No one has an obligation to respond to anyone's comments

This is a big misunderstanding of the W3C Process.

As a general rule, the VC WG has an obligation to respond to all comments raised in the issue tracker when refining a global standard and to record the final disposition of the comments (whether or not the commenter was satisfied with the changes made based on the discussion).

@TallTed you're becoming a bit overbearing IMO.

He is taking time out of his day in an attempt to help you refine the way you're communicating so that it results in actual change to the specification and is helping to elaborate upon the standard rules of engagement when it comes to global standards.

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.6. Define v2 context (issue vc-data-model#480)

See github issue vc-data-model#480.

Kristina Yasuda: Issue raises issues about "credentialSubject"..

Kristina Yasuda: See Manu's summary of the discussion.

Kristina Yasuda: There is a comment by Manu that summarizes the discussion. I suggest we close it, considering that the question has been answered..

Manu Sporny: +1 to close.

Kristina Yasuda: Anyone opposed to "pending close"?.

Orie Steele: +1 to close.

Dave Longley: +1 to close.

[brentzundel]

No comments since makred pending close, closing.