15:02:14 <RRSAgent> RRSAgent has joined #vcwg-special
15:02:18 <RRSAgent> logging to https://www.w3.org/2023/10/03-vcwg-special-irc
15:02:18 <Will> Will has joined #vcwg-special
15:02:18 <PL-ASU> present+
15:02:19 <Will> present+
15:02:25 <addison> present+
15:02:48 <ivan> present+
15:03:29 <manu> present+
15:03:29 <shigeya> present+
15:03:31 <TallTed> present+
15:04:00 <seabass> present+
15:04:02 <kristina> kristina has joined #vcwg-special
15:04:03 <seabass> scribe+
15:04:06 <seabass> Is there some feedback on audio for anyone else?
15:04:12 <ivan> rrsagent, draft minutes
15:04:13 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/03-vcwg-special-minutes.html ivan
15:04:15 <decentralgabe> decentralgabe has joined #vcwg-special
15:04:15 <decentralgabe> present+
15:04:39 <TallTed> RRSAgent, make logs public
15:04:40 <Zakim> Zakim has joined #vcwg-special
15:04:40 <kristina> present+
15:05:10 <andres> andres has joined #vcwg-special
15:05:14 <andres> present+
15:05:37 <dlongley> present+
15:05:42 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on I18N review for VCDM
15:05:42 <ivan> Date: 2023-10-03
15:05:42 <ivan> chair: kristina
15:05:42 <ivan> Agenda: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231003T110000/
15:05:49 <manu> rrsagent, draft minutes
15:05:50 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/03-vcwg-special-minutes.html manu
15:06:08 <seabass> kristina: Special meeting due to feedback on Internationalization.
15:06:12 <ivan> rrsagent, who is here?
15:06:12 <RRSAgent> I'm logging.  Sorry, nothing found for 'who is here'
15:06:54 <ivan> present+ Addison_Phillips
15:07:02 <manu> q+ to request reviews from Mike Jones
15:07:09 <seabass> kristina: Existing options had not been decided on.
15:07:20 <ivan> topic: I18n review
15:07:23 <kristina> ack manu
15:07:23 <Zakim> manu, you wanted to request reviews from Mike Jones
15:08:28 <selfissued> selfissued has joined #vcwg-special
15:08:30 <manu> selfissued, can you please review: https://github.com/w3c/vc-data-integrity/pull/196
15:08:30 <seabass> manu: Mike Jones, please would you review the multibase PRs.
15:08:32 <selfissued> present+
15:08:36 <manu> https://github.com/w3c/vc-di-ecdsa/pull/42
15:08:39 <manu> https://github.com/w3c/vc-di-eddsa/pull/63
15:09:14 <kristina> topic: interntionalization WG review
15:09:33 <seabass> kristina: Please introduce yourself Addison.
15:09:33 <kristina> https://github.com/w3c/vc-data-model/issues/1155
15:09:37 <kristina> https://github.com/w3c/vc-data-model/issues/1264
15:09:41 <kristina> https://github.com/w3c/vc-data-model/pull/1271
15:09:44 <manu> q+ to provide some background
15:09:44 <seabass> addison: I'm the chair of the I18N group at the W3C.
15:09:58 <kristina> three options? https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665
15:09:59 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
15:10:01 <ivan> s/interntionalization/Internationalization/
15:10:16 <kristina> ack manu
15:10:16 <Zakim> manu, you wanted to provide some background
15:11:07 <seabass> manu: The background of this: we've had guidance about supporting internationalization, with a design pattern for people to follow. In the 1.0 and 1.1 work, we haven't seen much adoption of the I18N features.
15:11:10 <ivan> present+ jandrieu, dwaite
15:11:31 <seabass> manu: For 2.0, we are adding two fields expected to be multilingual.
15:12:07 <manu> Here are the potential options that we're considering: https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665
15:12:14 <seabass> manu: We had a number of options to consider for how to do it in 2.0
15:12:49 <kristina> s/three options/five options
15:12:51 <ivan> present+ kristina, gabe, dmitri, orie,
15:13:11 <seabass> manu: We're looking to get to consensus on the option that we should choose, and one that will satisfy the I18N group.
15:13:23 <kristina> ack addision
15:13:23 <ivan> present+ pauld
15:13:44 <seabass> addison: I had read through the summary of the discussion and will summarise here to ensure that we have a common understanding.
15:14:24 <seabass> addison: In general, the I18N Group would like to see that any natural language string field has metadata about at least A: language and B: text direction.
15:15:09 <Orie_> Orie_ has joined #vcwg-special
15:15:09 <Orie_> present+
15:15:09 <seabass> addison: We aren't prescriptive about how that is performed. We also like to see a default language for documents.
15:15:31 <Orie_> It would be good to get a stronger opinionated recommendation regarding approaches.
15:16:01 <kristina> we kind of have 1.90 foot in LD world
15:16:11 <seabass> addison: I think it sounds like being somewhat in the Linked Data world as well as a more general specification produces some complications.
15:16:52 <seabass> addison: We would like to understand more the concerns around global @language directives, because we are wondering whether these concerns apply to the wider LD community.
15:16:52 <kristina> q?
15:16:52 <manu> q+ to mention challenges w/ proposed approaches; take some options off of the table.
15:17:09 <seabass> addison: From what we've learnt so far, the I18N group is trying to produce best practice recommendations to other groups.
15:17:51 <dlongley> i think we have both feet in LD world, we just want to use the simplest on ramps
15:17:51 <seabass> addison: One of the ones that we've already been working on is quite different from your approach. I would like to share it with you.
15:17:58 <dlongley> and adding `@value`, `@language`, and `@direction` in fields locally is the easiest way to do that
15:17:58 <kristina> ack manu
15:17:58 <Zakim> manu, you wanted to mention challenges w/ proposed approaches; take some options off of the table.
15:18:40 <dmitriz> dmitriz has joined #vcwg-special
15:18:46 <seabass> manu: On the topic of being both in the LD world and not, it seems like a subset of our community are less likely to adopt the specification when LD features are added.
15:18:53 <Orie_> -1 to asserting that "avoiding using LD is a possibility at this point".
15:19:09 <seabass> manu: We've tried to reduce the LD features to a minimum up until now.
15:19:18 <dlongley> -1 that we can / are avoiding it, +1 that we're choosing the easiest on ramps.
15:19:30 <seabass> manu: As for Option E (using a translation file), I think you mentioned that you were against it, and there seems to be agreement within this WG.
15:19:34 <seabass> q+
15:19:47 <seabass> q- later after addison
15:19:47 <Orie_> -1 to being vague about understanding conforming documents (which are JSON-LD in compact form).
15:20:36 <manu> q+
15:20:50 <manu> scribe+
15:20:52 <seabass> addison: I would not object to translation files per se, but I would point out technical complications about multiple requests and resources. I think that doesn't sound like the right pattern for credentials.
15:21:13 <kristina> ack manu
15:21:46 <seabass> manu: Option E can eliminated then!
15:22:24 <TallTed> s/on ramps/on-ramps/
15:22:48 <seabass> manu: For option D, I don't think this option has any advantages over using the LD method of a global @language, which is effectively the same in effect.
15:23:41 <seabass> addison: It is common for us to recommend that specifications do this. It would be better if there were generic mechanisms, but specification-specific fields are OK.
15:23:50 <dlongley> -1 to option D
15:24:02 <dlongley> -1 to option E
15:24:09 <shigeya> For the record: option E is externalization, and it will not be possible unless we define internal way to express it IMO.
15:24:09 <dlongley> +1 to eliminate E
15:24:09 <seabass> kristina: Are there any objections to eliminating option E?
15:24:15 <andres> +1 to eliminate E
15:24:15 <manu> +1 to eliminate option E
15:24:16 <shigeya> I'm fine with eliminating option E for now..
15:24:19 <PL-ASU> -1 to  option E & D
15:24:21 <JoeAndrieu> +1 to eliminate E
15:24:21 <seabass> q+ to eliminate
15:24:34 <seabass> q-
15:25:03 <andres> q+ to keep as a backup plan
15:25:08 <seabass> q+ to reply to option E, for real now ;)
15:25:15 <manu> +1 to eliminate option D (but keep it around as a backup plan)
15:25:26 <andres> q-
15:25:37 <seabass> addison: I would suggest that you could keep it for a 'backup'.
15:25:55 <seabass> andres: I think that's the default if we can't get consensus of anything else.
15:25:59 <manu> scribe+
15:26:07 <kristina> ack seabass
15:26:07 <Zakim> seabass, you wanted to reply to option E, for real now ;)
15:26:20 <manu> seabass: I wanted to mention option E with the translation files, sometimes they look really good on paper, but in practice, lots of complications.
15:27:17 <manu> seabass: networked translations, even when installed on computer, there are still lots of issues, GNU style translation -- .pot files -- translates based on literal value of string, but as linguists say, there are cases where you can have same words which mean two semantically different things and language files as used in GNU world don't have opportunity to disambiguate those. Number of complicates here with Option E.
15:27:42 <ivan> q+
15:27:48 <shigeya> I don't want to spend, but the way gettext/po used is studied well and in some non-english area esp. in CJK area, it's usuful.
15:27:54 <manu> q+ to keep going through options.
15:27:54 <kristina> ack ivan
15:27:54 <shigeya> s/spend/spend time/
15:28:10 <shigeya> s/usuful/useful
15:28:12 <seabass> I agree with addison: they can be used correctly but I think that is unlikely to be the case in the VC world.
15:29:21 <seabass> ivan: Option D means having two properties: language and text direction. We need both on the default level.
15:29:22 <manu> yes, that's the general agreement, I believe.
15:29:24 <seabass> ivan: Is this the general view as well?
15:29:31 <manu> We do need to express language AND direction
15:30:03 <seabass> addison: Indeed, I agree we would need to have this.
15:30:15 <manu>   "credentialSubject": {
15:30:15 <manu>     "myHumanReadableProperty": [{
15:30:15 <manu>       "@value": "This is some human-readable text.",
15:30:15 <manu>       "@language": "en"
15:30:16 <manu>   }, {
15:30:16 <manu>       "@value": "هذا بعض النص الذي يمكن قراءته بواسطة الإنسان.",
15:30:18 <manu>       "@language": "ar",
15:30:19 <kristina> q?
15:30:20 <manu>       "@direction": "rtl"
15:30:23 <kristina> ack manu
15:30:23 <Zakim> manu, you wanted to keep going through options.
15:30:23 <manu>   }]
15:30:50 <dlongley> +1 to this option (C, I believe), i think it's the simplest and will work generally for any natural field
15:30:54 <seabass> manu: We would express the value of the string, the language, and the text direction. I believe this meets the requirement that addison illustrated.
15:31:24 <dlongley> s/natural field/natural language field/
15:31:25 <dmitriz> +1 to option C, works well for multi-language credentials in Edu land
15:31:53 <PL-ASU> +1 to Option C, as it does indeed work well in edu-land.
15:32:01 <seabass> manu: We've mainly been discussing whether to alias the "@X" terms. Sebastian proposed options C on two occasions, and there were no objections raised. I believe it addresses all concerns except for the ability to specify a global default.
15:32:14 <seabass> +1 to Option C obviously :)
15:33:32 <seabass> manu: It's not easy to test this, as multiple languages are optional.
15:33:32 <manu> +1 to speaking to Option C in the specification.
15:33:33 <seabass> addison: I'm concerned that whilst the 'SHOULD' and 'MAY' are good supports for internationalisation, there will still be completely unlabeled strings.
15:34:22 <seabass> addison: I would like it to be possible to know a default, for when people don't want to put all the extra syntax in.
15:34:23 <manu> q+
15:34:26 <seabass> q+
15:34:29 <kristina> ack manu
15:35:07 <seabass> manu: Can we ask if the group is OK exploring option C further?
15:35:23 <DavidC> q+
15:35:24 <seabass> kristina: If anyone is strongly in objection to option C, please speak now.
15:35:25 <andres> q+ about langValue vs value
15:35:32 <kristina> ack seabass
15:35:45 <andres> q+ to ask about langValue vs value
15:36:17 <manu> seabass: To repeat for addisons' benefit -- VCs don't inherently have a language... language on field such as name/description is for human holder of VC in a wallet application. When you have the RDF world, link things together based on ontological truth, actual meaning...
15:36:48 <manu> seabass: you don't necessarily want to apply a language to the specific credential, you want to apply language to description of credential... that's why I like option C -- translate those human-readable values, credential itself doesn't have a language.
15:36:52 <Orie_> Conforming documents are represented in JSON-LD.... the philosophical concept of credentials is not helpful... JSON-LD will have text that is in a human readable language (both the term definitions, the text behind them, and their litteral values).
15:37:41 <manu> addison: Yes, important observation, locale-neutral data... when people talk about these things, name/description is how humans interact... can't look at other things and talk meaningfully about them... credential has BS of science -- those names/descriptions are of natural language pieces... want natural language to be associated with those parts, not other data.
15:38:05 <kristina> q?
15:38:16 <manu> addison: challenge is that machine generates these things, people writing code may or may not be willing to generate multiple language versions, or they may not wish to obtain and serialize information on per-field basis... if you're willing to say MUST, then we're good.
15:38:17 <seabass> addison: I think that's an important distinction: one wants to have language-neutral data if at all possible. A complication is that humans can't talk meaningfully about the pure data, only about the natural language descriptions.
15:38:17 <manu> q+
15:38:18 <seabass> q+
15:38:21 <kristina> ack DavidC
15:38:21 <seabass> scribe+
15:38:23 <manu> q+ to cover Option B
15:39:18 <seabass> DavidC: I think MUST is fine, but not sufficient. Let's say you have a degree from a Japanese university and has language metadata, that degree credential is still not readable by a typical English person.
15:39:35 <kristina> ack andres
15:39:35 <Zakim> andres, you wanted to ask about langValue vs value
15:39:38 <seabass> DavidC: I believe that C is necessary, but doesn't completely solve the internationalisation concerns.
15:39:45 <ivan> "necessary but not sufficient" +1 to that
15:40:28 <seabass> andres: I'm definitely supportive of Option C. In addition, I would like to see aliasing. I don't really understand why aliasing will cause problems with JSON-LD, so I would appreciate an explanation here.
15:40:30 <manu> q+ to try to say why langString is problematic.
15:40:31 <seabass> q- later to manu
15:40:51 <ivan> q+
15:40:58 <ivan> ack manu
15:40:58 <Zakim> manu, you wanted to cover Option B and to try to say why langString is problematic.
15:41:10 <dlongley> aliasing `@value` will alias it for everything, not just language values.
15:41:30 <Orie_> q+
15:41:30 <seabass> manu: The short answer is that '@value' is also used for non-natural-language fields. We can't just aliases it globally without making other fields have unwanted language features.
15:41:32 <dlongley> so making it say `langValue` (or whatever) for non-language values will be weird / confusing.
15:41:35 <kristina> q+ Orie
15:41:41 <kristina> q- Orie
15:42:23 <Orie_> The comment about "re-compacting" / "compacting" is critical for the WG to understandd
15:42:24 <seabass> manu: For that reason, I would be strongly opposed to aliasing if option C can be sufficient. It is only a single character difference.
15:42:38 <Orie_> I'm not sure that there is understanding here... and we should clarify
15:42:39 <seabass> andres: Thank you, that answered my question.
15:42:56 <seabass> manu: We would end up getting our alias appearing in unexpected places.
15:43:02 <manu> q+ to keep going through options, gotta get through them all.
15:43:07 <ivan> q-
15:43:54 <seabass> kristina: I would like to ensure that other options are considered as well and we are running out of time.
15:44:08 <manu> I'm afraid that we're not going to be able to get to "MUST always use @value/@language/@direction" when expressing human-readable strings.
15:45:06 <seabass> kristina: Let's discuss option B and A.
15:45:12 <dmitriz> +1 manu
15:45:38 <seabass> manu: The suggestion I'm hearing is to remove option A. It just allows us to use 'prettier' values, but doesn't have any advantage.
15:45:59 <Orie_> If folks don't understand "compact vs non compact LD"... they don't understand what a conforming document is.... so we should be cautious requiring "non compact" processing of languages, because they spec does not require people to understand that.
15:46:03 <Orie_> q-
15:46:25 <dlongley> if option B is putting `@language` as a default language in the context then -1 to that, it corrupts the data.
15:46:30 <seabass> manu: Option B provides a document-level default. The issue that we would need to flag is non-natural-language fields being classed as a specific language, such as Base64 data being marked as natural language.
15:46:58 <seabass> manu: We could make Option B a fallback to Option C, but that has downsides for the JSON-LD context architecture.
15:47:21 <kristina> ack manu
15:47:21 <Zakim> manu, you wanted to keep going through options, gotta get through them all.
15:47:23 <seabass> manu: I believe the options here are Option B+C -  OR -  Option C
15:47:58 <seabass> addison: You can't prevent people from serialising '@language' globally. You could deprecate that behaviour of course.
15:48:11 <kristina> s/ Option C/Option C+D
15:48:24 <kristina> ack seabass
15:48:24 <Zakim> seabass, you wanted to manu
15:49:19 <Orie_> IMO, if you can't stop people from doing something, its considered best practice to give them guidance... and not be silent.
15:49:22 <manu> seabass: I'd like to talk about Option C only
15:50:23 <ivan> q+
15:50:25 <manu> seabass: This is an implementation consideration, authenticate users, use existing libraries -- if those tools made it as easy to set a default in the code and have the serialization of fields automatic, as writing the serialized language feature at the top, then people would use that feature. In contrast to HTML, people were hand-writing it... but due to cryptography involved, people aren't hand-writing VCs. Lack of global language feature could
15:50:25 <manu> be side-stepped in implementations.
15:50:27 <kristina> I do not like the idea of let's rely on the library to implement thisi correctly..
15:50:30 <kristina> ack ivan
15:50:39 <shigeya> +1 kristina
15:50:43 <manu> q+ to see if there is a preference for C+B, C+D, or C-only?
15:51:25 <seabass> ivan: We could argue the same thing about HTML, as few people write HTML by hand. What's the proportion of tools that produce linguistically undefined documents? Perhaps addison knows.
15:52:05 <shigeya> It's depends on complexity of the output. for a simple VCs, it's not necessary to depends on huge library. not all people have freedom on memory and energy useage.
15:52:08 <seabass> ivan: Maybe putting the language metadata in all fields is a bit naive.
15:52:11 <hsano_> hsano_ has joined #vcwg-special
15:52:26 <shigeya> s/useage/usage
15:52:34 <kristina> q?
15:52:38 <seabass> ivan: I am not particularly partisan to the technique, but I think it's important to have something for global language.
15:53:21 <TallTed> can we globally say "language: undefined" or  "language: various" or similar?
15:53:23 <kristina> ack manu
15:53:23 <Zakim> manu, you wanted to see if there is a preference for C+B, C+D, or C-only?
15:53:40 <seabass> addison: To Sebastian's point, if you say that it's a MUST and all the libraries implement it, maybe it would be moot. I'm not sure that you could expect that response without a MUST.
15:53:43 <kristina> C+D
15:53:46 <ivan> C+B
15:53:56 <dmitriz> C+D for me
15:54:01 <seabass> C
15:54:25 <dlongley> -1 to C+B because it corrupts all string fields that are not natural language fields (which is a common thing in VCs)
15:54:31 <DavidC> c+d
15:54:42 <manu> C+B
15:54:47 <PL-ASU> C+B or if we're ranking 1, C+B, 2, B+C, 3, C
15:55:03 <dlongley> +1 to just C, I don't think there's a significant difference in MUST/SHOULD with C and having a default language with D, the people that don't want to do it won't do it either way -- and only tools will stop them
15:55:09 <dmitriz> wait D is in the VC core context or in the VC itself?
15:55:11 <PL-ASU> LOL
15:55:14 <seabass> q+ to make a suggestion of two-stage plan
15:55:20 <JoeAndrieu> +1 to C
15:55:24 <manu> D is in the VC itself.
15:55:28 <kristina> D is in VC itself I thnk
15:55:34 <shigeya> I think slightly C+B better but C+D is also acceptable.
15:55:44 <PL-ASU> S/1, C+B, 2, B+D, 3, C
15:56:11 <dlongley> q+
15:56:28 <dlongley> that's an insufficient description of B and D ...
15:56:39 <seabass> dmitriz (IRC): can we remind people of the difference between D and B?
15:56:39 <seabass> manu: D creates a new feature, B uses an existing JSON-LD feature.
15:56:40 <dlongley> B will use a JSON-LD feature that will apply a language to EVERY string field, even non-language fields
15:56:47 <dmitriz> in that case, C+B
15:56:48 <ivan> q+
15:56:48 <Orie_> I think I agree with what dimitry is saying though...
15:56:51 <dlongley> D will invent something new for VCs but only apply it to natural language text fields.
15:57:00 <Orie_> ^ yeah... that
15:57:08 <dlongley> q-
15:57:12 <kristina> q?
15:57:23 <PL-ASU> Ori is up
15:57:33 <kristina> ack ivan
15:57:50 <dlongley> q+
15:58:07 <seabass> ivan: dlongley said that every field will get a language tag with B. However, if we had LD tags for datatype, that won't be an issue.
15:58:17 <Orie_> q-
15:58:23 <dmitriz> agree with ivan
15:58:32 <seabass> ivan: It's not as bad as it looks considering the existence of those JSON-LD datatypes.
15:58:38 <kristina> ack dlongley
15:58:43 <dmitriz> an app somehow interpreting language & direction on a base64 string or whatever is /not/ a realistic problem
15:59:05 <seabass> dlongley: I agree with you that we should use datatypes, but the JOSE and COSE parts do not have data types defined.
15:59:11 <kristina> ack seabass
15:59:11 <Zakim> seabass, you wanted to make a suggestion of two-stage plan
15:59:22 <Orie_> also not necesary... to do... because the data model is COMPACT JSON_LD !!!!
15:59:23 <manu> seabass: It is a bit involved, I'll write to the mailing list, can we delay a vote for day or two to engage w/ email.
15:59:49 <seabass> kristina: We appreciate Addison's time. Thank you!
16:00:15 <ivan> rrsagent, draft minutes
16:00:16 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/03-vcwg-special-minutes.html ivan
16:00:41 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/03-vcwg-special-minutes.html addison
16:01:43 <ivan> zakim, end meeting
16:01:43 <Zakim> As of this point the attendees have been kristina, andres, dlongley, Addison_Phillips, selfissued, jandrieu, dwaite, gabe, dmitri, orie, pauld, Orie_
16:01:45 <Zakim> RRSAgent, please draft minutes
16:01:47 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/03-vcwg-special-minutes.html Zakim
16:01:52 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:01:52 <ivan> rrsagent, bye
16:01:52 <RRSAgent> I see no action items
16:01:53 <Zakim> Zakim has left #vcwg-special