14:54:06 <RRSAgent> RRSAgent has joined #vcwg-special
14:54:10 <RRSAgent> logging to https://www.w3.org/2023/08/22-vcwg-special-irc
14:54:10 <Zakim> RRSAgent, make logs Public
14:54:11 <Zakim> please title this meeting ("meeting: ..."), ivan
14:54:27 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on PR Discussions
14:54:27 <ivan> Date: 2023-08-22
14:54:27 <ivan> chair: brent
14:54:27 <ivan> Agenda: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20230822T110000/
14:54:27 <ivan> ivan has changed the topic to: Meeting Agenda 2023-08-22: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20230822T110000/
14:57:36 <brent> brent has joined #vcwg-special
15:00:05 <Orie> Orie has joined #vcwg-special
15:01:35 <brent> present+
15:02:08 <bigbluehat> present+
15:02:08 <seabass> present+
15:02:22 <decentralgabe> decentralgabe has joined #vcwg-special
15:02:26 <decentralgabe> present+
15:02:31 <shigeya> present+
15:02:33 <ivan> present+
15:02:42 <manu> present+
15:02:53 <Paul_DietrichGS1> Paul_DietrichGS1 has joined #vcwg-special
15:02:58 <Paul_DietrichGS1> scribe+
15:03:05 <ivan> present+ orie, TallTed , seabass
15:03:17 <ivan> present+ Paul_DietrichGS1
15:03:26 <brent> Topic: PRs
15:03:27 <brent> https://github.com/w3c/vc-data-model/pulls
15:03:31 <manu> q+
15:03:31 <ivan> present+ dlongley
15:03:34 <Paul_DietrichGS1> brent: primary topic for today is pull requests.
15:03:52 <brent> https://github.com/w3c/vc-data-model/pulls
15:03:55 <seabass> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3Apost-CR
15:04:03 <pl_asu> pl_asu has joined #vcwg-special
15:04:14 <dmitriz> dmitriz has joined #vcwg-special
15:04:32 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1172
15:04:33 <ivan> present+ davidc
15:04:37 <manu> q-
15:04:57 <Rachel> Rachel has joined #vcwg-special
15:05:10 <Paul_DietrichGS1> brent: when we last talked about this chairs expressed that if we could not find consensus we would want to close it.  Ted brought up this is a hard conversation to have in an issue.
15:05:16 <pl_asu> pl_asu has left #vcwg-special
15:05:23 <Orie> +1 to closing
15:05:24 <manu> q+
15:05:27 <Paul_DietrichGS1> . . . my inclination is to close unless there are objections today
15:05:35 <brent> ack manu
15:05:44 <Orie> +1 Manu!
15:06:09 <pl_asu_> pl_asu_ has joined #vcwg-special
15:06:12 <Paul_DietrichGS1> manu: we the group should learn something from this PR. Its hard to change terminology as its been worked on for years.  Start with an Issue and avoid scope creep.
15:06:18 <pl_asu_> present+
15:07:05 <Paul_DietrichGS1> ... the defitions were changed in a way that were more specific and accurate and correct but made it complex so the term ended up not being useful.   terminology section is probably not the place to do this.
15:07:06 <TallTed> s/. . . my/... my/
15:07:30 <Orie> This kind of PR might be more successful in use cases, implementation guide or other notes.
15:07:53 <Paul_DietrichGS1> brent: agree with observations and not heard any objects.  After this call I will close this.
15:08:00 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1199
15:08:17 <Orie> q+
15:09:01 <brent> ack Orie
15:09:01 <Paul_DietrichGS1> Orie: we had asked Joe to review again and he has concrete change requests here. Ted has a comment on them.I havent had a full change to review.
15:09:18 <hsano> hsano has joined #vcwg-special
15:09:46 <Paul_DietrichGS1> TallTed: I think Joes suggestion is good and does need a couple notes that I put in a comment below.  Other comment is not important at this time.
15:09:53 <Paul_DietrichGS1> brent: Orie, can you make that change.
15:10:07 <hsano> present+
15:10:25 <Paul_DietrichGS1> TallTed: I will put a suggestion and orie will merge.
15:10:37 <Orie> Just a note that Joe might have further objections after this is applied
15:10:38 <manu> q+
15:10:38 <Paul_DietrichGS1> brent: Expect this PR to be merged in the next day or so
15:10:40 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1238
15:11:09 <Paul_DietrichGS1> gabe: I have accepted all the suggestions outstanding and welcome further review.
15:11:42 <Paul_DietrichGS1> brent: Has been out for a week. encourage review. request for any other comments.
15:11:46 <brent> ack manu
15:11:55 <smccown> smccown has joined #vcwg-special
15:12:05 <smccown> present
15:12:07 <Paul_DietrichGS1> manu: I think this PR is ready to go.  All other PR are less than 2 days old. suggest that we skip them.
15:12:17 <cabernet> cabernet has joined #vcwg-special
15:12:20 <cabernet> present+
15:12:20 <seabass> q+
15:12:23 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1249
15:12:28 <Paul_DietrichGS1> brent: I'm inclined to go through them as normal.
15:12:30 <brent> ack seabass
15:12:32 <ivan> present+ cabernet
15:12:47 <ivan> present+ smccown
15:13:02 <Paul_DietrichGS1> seabass: would it not be better to have a glossary, referring to PR 1238.
15:13:02 <manu> q+ to comment on wikipedia links
15:13:06 <Orie> yeah, agree regarding the wikipedia citations.
15:13:07 <Paul_DietrichGS1> brent: apologies, we had just moved on.
15:13:18 <brent> ack manu
15:13:18 <Zakim> manu, you wanted to comment on wikipedia links
15:13:52 <decentralgabe> note: we had already linked to wikipedia, I just did it more
15:14:06 <Paul_DietrichGS1> manu: I think its fine to link out to wikipedia in sections that are non normative.  May be that wikipedia is a better place for this definition than the spec.
15:14:12 <Orie> +1 Manu
15:14:14 <shigeya> I agree with Manu on this references.
15:14:36 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1249
15:14:42 <Paul_DietrichGS1> brent: move on to 1249
15:14:54 <Paul_DietrichGS1> brent: this PR has had some review and comments. Manu can you summarize
15:15:10 <andres> andres has joined #vcwg-special
15:15:15 <andres> present+
15:16:23 <Paul_DietrichGS1> manu: Jeffery said that you dont give concrete guidance on what to do if the base context hash is differen than what you expected.  This updates the spec that provides language around this so its impossible for it to be anything different than what it is.
15:16:33 <DavidC> DavidC has joined #vcwg-special
15:16:37 <DavidC> present+
15:16:46 <Paul_DietrichGS1> ... gabe asked whether we expect this to be immutable., yes unless we make a mistake and then we will update them.
15:16:51 <Orie> I would say *no, not immutable* hence the comments about errata and cache timing.
15:17:01 <Paul_DietrichGS1> brent: any comments on this PR before we move forward.
15:17:15 <manu> q+
15:17:16 <Paul_DietrichGS1> brent: moving to 1250
15:17:28 <DavidC> q+
15:17:34 <Orie> https://github.com/w3c/vc-data-model/pull/1250/files
15:18:06 <Paul_DietrichGS1> ... this PR has lots of approvals as well as questions from ted that have been addressed
15:18:06 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1250
15:18:11 <brentz> brentz has joined #vcwg-special
15:18:25 <brentz> ack manu
15:19:19 <Paul_DietrichGS1> manu: this items applies range requirements for valid from and valid until.  We didn't specify that one had to be larger than the other.  We also have language that says that the datetime value has to be temporally the same.
15:19:43 <Orie> q+
15:20:01 <Paul_DietrichGS1> ... gabe pointed out that the language could be confusing. Interested in other peoples feedback.  Do we need to go into details about value space and lexical space.
15:20:06 <decentralgabe> q+
15:20:15 <Paul_DietrichGS1> ... so far lots of approvals.  Looking for feedback from gabe.
15:20:19 <brentz> ack DavidC
15:21:02 <Paul_DietrichGS1> DavidC: we had wording we aggreed to in the issue, but its not in the version I am looking at.
15:21:12 <Paul_DietrichGS1> TallTed: Its in the whilte background in the PR.
15:21:18 <TallTed> https://github.com/w3c/vc-data-model/pull/1250/files
15:21:22 <Paul_DietrichGS1> DavidC: I clicked on the diff with the version for the 22nd of Aug (Today)
15:21:34 <Paul_DietrichGS1> manu: It is there David as Ted Said. Lines 1674-1676.
15:21:40 <Orie> I don't see it in the diff.
15:21:44 <Paul_DietrichGS1> DavidC: It doesn't show in the PR diff bit.
15:21:48 <Orie> because its already been added previously
15:21:58 <Paul_DietrichGS1> manu: it was made previously in another diff.
15:22:28 <Paul_DietrichGS1> Tallted: Do you see one version on left and one on right?
15:23:13 <Paul_DietrichGS1> tallted: instead of clicking the preview, click the link in the IRC chat.
15:23:30 <Paul_DietrichGS1> DavidC: Im looking in zoom and see the blue highlight.  What about in the past?
15:23:41 <Paul_DietrichGS1> tallted: its below in the next section
15:23:57 <Paul_DietrichGS1> DavidC: The point I am making is that the validFrom can be in the past, not just validUntil.
15:24:20 <Paul_DietrichGS1> tallted: you want to say that both validFrom and validUntil could be future or past or anywhere.
15:24:24 <Paul_DietrichGS1> DavidC: yes
15:24:36 <Paul_DietrichGS1> tallted: we can put in on both.  and take it offline.
15:24:41 <brentz> q?
15:24:48 <brentz> ack Orie
15:25:25 <Paul_DietrichGS1> Orie: a brief comment on temporally means will help.  The things that should be clear to everyone is that these are string representations.  I could imagine people having use cases
15:25:58 <brentz> ack decentralgabe
15:26:01 <Paul_DietrichGS1> ... for valid from an validUntil that are not these string formats, but you can't use these terms for that kind of thing.  A quick sentence on what temporally means would be hekpful but this could go in as written.
15:26:29 <manu> q+
15:26:38 <manu> q+ to add some language on what is meant by "temporally"
15:26:43 <brentz> ack manu
15:26:43 <Zakim> manu, you wanted to add some language on what is meant by "temporally"
15:26:48 <Orie> I agree, comparing strings seems safer, than comparing values, but time is hard.
15:26:53 <Paul_DietrichGS1> gabe: my concern is that there could be implementation bugs. small risk of implementation bug, but I dont think its a big deal.
15:27:00 <Paul_DietrichGS1> manu: I will add some language on what temporally means
15:27:22 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1251
15:27:43 <manu> q+
15:27:48 <brentz> ack manu
15:27:48 <Paul_DietrichGS1> brent: this on is in direct response to comments. Has nothing but approval so far.
15:28:34 <ivan> present+ dmitriz
15:28:44 <Paul_DietrichGS1> manu: when Jeffrey did his review of our specs, he said that he noted we made the context normative and referenced other specs at a lesser level of maturity. This could slow down VC data model from getting to req. Or if it goes to req, you may be limiting your dependencies.
15:29:09 <Paul_DietrichGS1> ... this could make other specs like statusList VC JOSE COSE unable to change because the data model locked them in.
15:30:02 <Paul_DietrichGS1> ... This PR expresses the strategy to deal with this as we move to CR>
15:30:10 <ivan> q+
15:30:18 <brentz> ack ivan
15:30:57 <Orie> +1 to exact timing, especially given our bundling strategy in vc data model.
15:31:03 <Paul_DietrichGS1> ivan: we should aim at producing the recommendations at exactly at the same. Why can we do one recommendation with all the documents.
15:31:03 <manu> I'd be fine w/ exactly... we'll be doing it towards next April/May-ish timeframe, probably.
15:31:13 <manu> q+
15:31:20 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1252
15:31:29 <brentz> ack manu
15:32:13 <Paul_DietrichGS1> manu:  this adds name and description to the data model.  A bit unsure about what to do. Addison did a review on name a desrciption and we don;t have a good internationalization story for these.
15:32:15 <ivan> q+
15:32:18 <dmitriz> q+
15:32:53 <Paul_DietrichGS1> ... there are places around the world that have legal requirements to publish in multiple languages. This may require these countries to issue multiple credentials in multiple languages.
15:33:07 <dmitriz> q-
15:33:19 <Paul_DietrichGS1> ... JSON-LD has a straightforward internationalization story, but with the JSON processing mechanism we don't quite have it.  We could use the same patterm.
15:33:56 <Paul_DietrichGS1> .. If we want to express multiple languages you would use an array with each item in the array being an expression.
15:34:22 <Paul_DietrichGS1> ... that is the proposal here. That does not prevent someone from using just plain text string.
15:34:44 <Orie> q+
15:34:50 <brentz> ack ivan
15:34:55 <DavidC> q+
15:35:48 <brentz> ack Orie
15:35:52 <Paul_DietrichGS1> ivan: the reason I queued is to say we already have an internationalization story in the document. I fully agree we should take over what is there.  There is no standard story for internationalization in the JSON land so whatever we do we would have to invent something.
15:36:18 <Paul_DietrichGS1> Orie: recommend referencing on internationalization section with concrete advice.  We could ask for an internationalization review.  Could be relevant to us.
15:36:43 <Paul_DietrichGS1> ... we should have one section to consistently refer to for this and reference that section here.
15:36:46 <brentz> ack DavidC
15:36:58 <seabass> q+ to ask for clarification from Orie
15:37:19 <Paul_DietrichGS1> DavidC: I agree and like Manus idea.  It could either be in this example or as Orie suggested it could be a separate section with an example. Somehwere in the document we should have an example
15:37:20 <brentz> ack seabass
15:37:20 <Zakim> seabass, you wanted to ask for clarification from Orie
15:37:41 <Orie> q+
15:37:45 <Paul_DietrichGS1> seabass: Wanted to ask Orie.  What do you mean by string style here?
15:37:50 <brentz> ack Orie
15:38:01 <TallTed> s/string style/strings file/
15:38:13 <ivan> q+
15:38:37 <Paul_DietrichGS1> orie: weve talked about this a pretty long time ago. The original examples included the JSON LD language feature.  There was discussion that that wasn't used widely and that it was an experiment and not a good use for this. In other application they use strings files for this kind of thing.
15:38:46 <shigeya> That's what I said long ago...
15:39:01 <Paul_DietrichGS1> ...I think there was discussion but nothing concrete happened. I was summarizing the previous comments I remembered around internationalization.
15:39:03 <shigeya> q+
15:39:21 <brentz> ack ivan
15:39:45 <seabass> q+ to respond to Orie
15:40:06 <brentz> ack shigeya
15:40:08 <Paul_DietrichGS1> ivan: I was part of the earlier discussions in the previous version of the working group. As far as I know the language feature of JSON LD is stable and used.  I don't see a problem with it.
15:40:55 <manu> q+
15:41:29 <Paul_DietrichGS1> shigeya: from my point of view, the discussion I had that was happening prior to the decision we made.  We are based on JSON LD construct which seems to be good enough.
15:42:07 <Paul_DietrichGS1> .. what I current observe is how we want to express the construct in JSON LD .  I think that what we want to do is (as Ivan mention) is how we address this in the spec text.
15:42:16 <Orie> if its possible to not leave i18n a "choose your own adventure" that seems like a good idea, either recommend `@langauge` or recommend against it.
15:42:59 <Paul_DietrichGS1> ... I think the mapping strings is useful, but this construct is not discussed until now.  Its a bit too late to discuss this. I will try to write a document with regards to the extension point but its doubtful to be part of the standard.
15:43:03 <brentz> ack seabass
15:43:03 <Zakim> seabass, you wanted to respond to Orie
15:43:07 <ivan> s/langauge/language/
15:43:29 <Orie> q+
15:43:44 <Paul_DietrichGS1> seabass:  would you object to create a PR to the issue using the JSON LD contstruct?
15:43:47 <brentz> ack manu
15:44:06 <manu> The current proposal would end up looking something like this: "name": [{"value": "This is in English", "lang": "en-US"}, {"value": "هذا باللغة العربية", "lang": "ar", "dir": "rtl"}]
15:44:56 <Paul_DietrichGS1> manu: describing the example he put in the minutes above.  The only problem is that people haven't been using this, and avoiding internationalization.
15:46:06 <Paul_DietrichGS1> ... shigeya did suggest we use an external document that does translation, but to date we have not had a concrete proposal and we are out of time. Not clear if that proposal would get better traction.  What we are proposing now does not prevent this potentially better proposal from happening the future.  The way that we are doing this does not require JSON LD processing. Its a design pattern for JSON.
15:46:10 <Orie> I agree with basically everything manu said.
15:46:16 <seabass> q+
15:46:21 <brentz> ack Orie
15:46:46 <manu> We will provide an example, we will provide concrete language, we will provide a warning.
15:46:59 <manu> at least, I intend to update the PR with the above ^
15:47:03 <Paul_DietrichGS1> Orie: to be concrete in the recommendation. We should provide an example like what manu shared. We should provide a warning that not many people are doing this and that in the future there could be other mechanisms.
15:47:10 <dmitriz> q+ to re "applications are not doing this"
15:47:41 <Paul_DietrichGS1> ... it would be better to be direct around challenges and provide text in one section.
15:47:42 <brentz> ack seabass
15:47:50 <dlongley> +1 to continuing to follow our approach of defining what should be done in the VCDM by just reusing what JSON-LD already does
15:48:12 <dlongley> and adding the appropriate aliases as needed
15:48:19 <Paul_DietrichGS1> seabass: I will create a PR to describe examples of using the JSON LD language concept and that say in the future we may add something to the VC context to do without jSON-LD processing.
15:48:20 <brentz> ack to
15:48:20 <Zakim> to, you wanted to discuss "applications are not doing this"
15:48:49 <dlongley> +1 to Dmitri's comments on "this is new"
15:48:56 <Paul_DietrichGS1> dmitriz: Its not that big of a deal. In a spec that is just being baked, its clear that not alot of people are doing this. This kind of language seems useless.
15:48:57 <shigeya> +1
15:49:14 <Paul_DietrichGS1> brent: A concrete path forward for this PR and other. Time to look at last open PR. 1253
15:49:16 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1253
15:49:16 <Orie> it's true, but internationalization can cause lots of drama... so it deserves extra caution... see IDNA.
15:51:00 <Paul_DietrichGS1> ivan: there was another one 1241 with a lot of approval. I came in a bit late and there were some things missing. I proposed to do another PR over that PR to simplify things. While doing this, I realized that the PR would lead to all kinds of merging problems because in the meantime other PRs were merged.  So1253 is 1241 plus some minor additions.  I would expect that the people that reviewed 1241 their approval would be[CUT]
15:51:12 <manu> PR #1253 and #1241 is looking good...
15:51:16 <Paul_DietrichGS1> ... make a final decision.  1253 is 1241 plus some requested changes.
15:51:56 <Paul_DietrichGS1> brent: based on that and 1241 was around for a week and had nothing but approvals. I anticipate 1253 will be merged soon.
15:52:55 <Paul_DietrichGS1> brent: adjourn until tomorrow. Its a goal of this working group that every before-CR labeled issue have a PR before TPAC.  That is 3 weeks from now.  If you have an assignment for one of these issues, please raise a PR
15:53:02 <Paul_DietrichGS1> scribe-
15:53:04 <ivan> rrsagent, draft minutes
15:53:05 <RRSAgent> I have made the request to generate https://www.w3.org/2023/08/22-vcwg-special-minutes.html ivan
15:53:18 <ivan> zakim, end meeting
15:53:18 <Zakim> As of this point the attendees have been brent, bigbluehat, seabass, decentralgabe, shigeya, ivan, manu, orie, TallTed, Paul_DietrichGS1, dlongley, davidc, pl_asu_, hsano,
15:53:21 <Zakim> ... cabernet, smccown, andres, dmitriz
15:53:21 <Zakim> RRSAgent, please draft minutes
15:53:23 <RRSAgent> I have made the request to generate https://www.w3.org/2023/08/22-vcwg-special-minutes.html Zakim
15:54:01 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:54:01 <Zakim> Zakim has left #vcwg-special