15:40:45 RRSAgent has joined #vcwg-special 15:40:45 logging to https://www.w3.org/2022/11/29-vcwg-special-irc 15:40:47 RRSAgent, make logs Public 15:40:48 please title this meeting ("meeting: ..."), ivan 15:41:31 Meeting: Verifiable Credentials Working Group Special Topic Call on `@context` and `@vocab` 15:41:31 Date: 2022-11-29 15:41:31 chair: brent 15:41:31 Agenda: https://www.w3.org/events/meetings/e410bbbd-57c4-46cc-b279-674cc53a58e8/20221129T110000 15:41:31 ivan has changed the topic to: Meeting Agenda 2022-11-01: https://www.w3.org/events/meetings/e410bbbd-57c4-46cc-b279-674cc53a58e8/20221129T110000 15:42:16 ivan has changed the topic to: Meeting Agenda 2022-11-29: https://www.w3.org/events/meetings/e410bbbd-57c4-46cc-b279-674cc53a58e8/20221129T110000 15:59:57 cel has joined #vcwg-special 16:01:12 csarven has joined #vcwg-special 16:01:15 ChristopherA_ has joined #vcwg-special 16:01:16 present+ 16:01:19 JoeAndrieu_ has joined #vcwg-special 16:01:21 present+ 16:01:29 present+ 16:01:29 present+ 16:01:30 mpororck has joined #vcwg-special 16:01:35 David_Waite has joined #vcwg-special 16:01:36 kristina has joined #vcwg-special 16:01:37 present+ 16:01:41 present+ 16:01:42 present+ 16:01:57 selfissued has joined #vcwg-special 16:02:06 Orie has joined #vcwg-special 16:02:24 present+ 16:02:34 present+ 16:02:43 chair: kristina 16:02:50 present+ 16:02:52 andres has joined #vcwg-special 16:02:55 present+ 16:03:03 drummond has joined #vcwg-special 16:03:04 scribe+ sarven 16:03:05 Yan_Dappworks has joined #vcwg-special 16:03:16 present+ 16:04:10 brentz has joined #vcwg-special 16:04:23 dmitriz has joined #vcwg-special 16:04:27 present+ 16:04:30 present+ 16:05:03 zakim, who is here? 16:05:03 Present: dlongley, csarven, ChristopherA_, JoeAndrieu_, mpororck, kristina, David_Waite, ivan, Orie, selfissued, cel, drummond, brentz, dmitriz 16:05:05 On IRC I see dmitriz, brentz, Yan_Dappworks, drummond, andres, Orie, selfissued, kristina, David_Waite, mpororck, JoeAndrieu_, ChristopherA_, csarven, cel, RRSAgent, Zakim, ivan, 16:05:05 ... stenr, manu, dlongley 16:05:15 present+ manu-irc-from-an-airplane 16:05:29 decentralgabe has joined #vcwg-special 16:05:30 csarven: Chair the Solid CG. Works at Inrupt. 16:05:34 present+ 16:05:52 DavidC has joined #vcwg-special 16:05:59 dlehn1 has joined #vcwg-special 16:05:59 present+ davidc 16:06:24 present+ Phil-ASU 16:07:36 present+ andres 16:08:11 kristina: Sent out the summary as requested as last special topic call. It has some reactions. 16:08:14 present+ 16:08:17 q+ 16:08:18 TallTed has joined #vcwg-special 16:08:22 kristina: Any proposals on the table or any topics people would like to discuss? 16:08:28 q+ 16:08:43 ack Orie 16:09:10 Orie: I sent the response to the summary for the previous special topic call. There were two polls succeeded in explaining reasonable amount of agreement. Building on the two. Responded to the list with proposals. 16:09:40 present+ abramson 16:09:45 Orie: In particular the ??? vocab. Th epoll had a lot of optionality. Where that ??? vocab could go. First context or second. It wasn't clear where we might want to put that vocab, and where in various locations. 16:09:49 shawnb_ has joined #vcwg-special 16:09:54 present+ 16:09:57 present+ 16:10:24 Orie: There are several issues discussed some months now. Side conversations. A shared / personal position where it can put value for issuers/verified. Summarised earlier but people probably didn't get a chance to review yet. 16:10:55 Orie: In this call, we could elaborate on why they are used in some places (e.g., schema.org). The use of vocab and would like to run the value. 16:11:04 s/??? vocab/`@vocab`/ 16:11:10 Orie: If we can run the polls on where those distributions would be... 16:11:15 ack selfissued 16:11:27 Username place. 16:11:30 *please 16:11:30 present+ cabernet 16:11:36 q+ 16:11:47 Related issue: https://github.com/w3c/vc-data-model/issues/953 16:11:52 ... I'd like disucss what those CBOR mapping would be. I have 3 potential poll questions. 16:12:20 selfissued: I am sensitive to that. Some of these things intertwined. A data model non-JSON that affects the core data model. WOuld like time for that. 16:12:25 +1 to mike's questions 16:12:29 ack Orie 16:13:01 Orie: The idea of discussing CBOR after the issue that has been filed and without the WG having time to evaluate.. I think it may not be good use of the special topic call. 16:13:08 q+ 16:13:22 +1 to Orie, many people may not have even seen the new CBOR issue(s?) 16:13:30 Orie: I'd like to get more debate on the issue tracker. Talk about CBOR. 16:13:45 present+ gabe 16:13:51 Orie: It is starting to get a bit painful for the WG. I can see the intention that others have expressed on this point. 16:13:53 +1 to progress - but would like to be mindful of how we would map to CBOR as we lock in core data model 16:14:09 +1 to separate special topic call like Orie says 16:14:12 ack ChristopherA_ 16:14:13 Orie: I am struggling to .. we should have a special topic call on CBOR and have th econversations out befor ethe call. That'd be my request from the chairs. 16:14:46 ChristopherA_: I'd like to see a special call on CBOR. One of th ekey questions is how closesly does it conform to certain kinds of decisions vocab, context and other stuff for it to be a utility to this group. 16:15:02 ChristopherA_: Depending on how you frame it being firm about some of those things could cause complications. 16:15:14 jeremie__ has joined #vcwg-special 16:15:18 My "Enable CBOR Representations" issue is https://github.com/w3c/vc-data-model/issues/985 16:15:18 ChristopherA_: ... Anonymity ??? I'd like to preserve. 16:15:36 +1 I think CBOR can be addressed without causing the core data model to be rewritten, I believe we can discuss that on issues, and then in a dedicated topic call. 16:15:47 kristina: Even if we have a dedicated call on CBOR we need ot see the WG stands on that topic. 16:15:47 +1 to Orie 16:15:48 present+ Geun-Hyung 16:16:04 +1 separate call on CBOR -- that's a big topic and one that the group needs some background on to discuss. 16:16:15 wip has joined #vcwg-special 16:16:17 Can someone remind me commands related to topics/proposal setc.. 16:16:58 q+ to mention implications to changing vocabs later 16:17:03 Kerri_Lemoie_ has joined #vcwg-special 16:17:27 Orie: The last poll we ran we had talked about including the vocab in the context (next version of the context v2). In v1 there was no vocab. That means that if you don't add a second context then anything you include in the credentials there';;l be errors. .. A bunch of scenarios., e.g, integrity. This will make the first ocntext that you'll ever need for JSON-LD processing and also safe to completely ignore to assign a single URL to it and 16:17:27 retain the core model. 16:17:29 Phil has joined #vcwg-special 16:17:49 q? 16:18:12 Orie: It is on the list and debated for awhile now. THe key part of this proposal is base IRI that the WG uses.. I have other propsoals where different IRI bases will do. What the tradeoffs are. I'd lke to evlauate up front. We can see to include ??? in the primary ??? 16:18:37 Yan_Dappworks has joined #vcwg-special 16:18:42 Don't have bandwidth to study that now TallTed :) 16:18:43 ack dlongley 16:18:43 dlongley, you wanted to mention implications to changing vocabs later 16:19:06 dlongley: the impact to change the vocab later. if this is put into v2 context where we only have one v2 context. 16:19:32 Related to dave's comment, here is an example of the behavior today: https://v.jsld.org/3xq8SHD6DXJg1tZKHeLqJqhA3vZLm9kjVFyBvhrFYacmJgja5SnM5GWfLthVGijeqMfv1LhcjQ1KT8rhubhAHszUyhC7WbcgQQypie6u7nMFVSeGFA46TYAzf7eXa2btVxbhoDqSgDXsmTLi5rKqWmB2iTK74UsLu5QkT4wVp31o7GoBLXs1GRtCN6Bi7sh7Skmu14ikNbX1Ss51TrYxnRDv2erzof75SSEuiu855hJ9KtzD58zuF 16:20:03 dlongley: I don't know if I'd take issue that it might come challenging. json and json-ld processing. having vocab and base context. other people might want to add additional context that @vocab value that could cause complications on how data is process so something to keep in mind. there are other ways around this. two different core context have one ??? and one doesn't. there may be challenges to including two 16:20:09 q? 16:20:31 PROPOSAL: The v2 `@context` will contain an `@vocab` with a base IRI that the working group chooses. 16:20:37 +1 16:20:38 +1 16:20:38 0 16:20:39 +1 16:20:44 +1 16:20:46 +1 16:20:48 +0 16:20:48 0 16:20:49 0 16:20:51 0 16:20:52 +0 (non-blocking, open to addressing any processing problems in another way) 16:20:52 0 16:20:52 +1 16:20:57 -0 16:20:58 0 16:21:00 0 16:21:01 +0 16:21:02 -0 16:21:03 +0 16:21:04 +1 16:21:05 0 16:21:10 0 16:21:28 0 16:21:31 (I'm really more -0) 16:21:46 q+ to talk about resolutions made on this call 16:22:01 cabernet has joined #vcwg-special 16:22:09 present+ 16:22:11 Orie: The 0s may generally reflect the the unsurity .. 16:22:25 present+ 16:22:47 uneasy, more than unsure, here 16:23:04 present+ Yan_Dappworks 16:23:12 DB would prefer @vocab in 2nd context... we'd +1 that, I believe. 16:23:29 Isn't that what LD @context statements do already? What is different about @vocab? 16:23:36 That is, we feel that approach doesn't have any downsides) 16:23:50 @drummond - I had that same question. 16:23:59 No, that's not what @context does, Drummond... it doesn't establish a "default vocabuary"... @vocab establishes a default vocabulary. 16:24:15 (can @vocab model also work with labeled property graph style architectures?) 16:24:23 @drummond - @vocab is basically a safety net / catch-all for all terms not defined in the context 16:24:27 So, we're talking about either establishing a default vocabulary for ALL VCs... or a default vocabulary on a per-market vertical basis. 16:24:35 q+ 16:24:35 `@vocab` "auto-defines" term mappings ... so any JSON key, e.g., "foo" will automatically map to a globally unambiguous URL like "https://example.com/foo" 16:24:44 basically an @vocab at the base context preserves ability for property graphs while enabling private claims 16:24:47 Orie: ??? How vocab is used ot expand IRIs. It is a way to take a turn and get an unambigious reference to that term e.g., subject property in RFC< the string is not a lot uniqueness but that ??? refernece ??? where the domain si complex e.g. assertion, attestation. it can help to have a human-readable definition for a term. the vocab gives an ide ntifier in an easy way. can expand with URN but then you don't want anyone to resolve that in a 16:24:47 human-readable in a web borwser. jus want to ge ta unique definition for it. if you talk about the evidence property. w3c may define in a technical def. and we'd host a normative def. we could do that at urn rooted at w3c. what i watned to do was to use URN to see if people have storng feelings on URNs. 16:25:09 `@vocab`, when included in a context, auto-generates mappings vs. them being explicitly provided on a term-by-term basis. 16:25:21 q+ 16:25:31 It's snowing in Redmond - first snow of the winter! 16:25:56 q+ 16:25:58 The JSON-LD 1.1 spec: https://www.w3.org/TR/json-ld11/ 16:26:01 q+ to explain @vocab quickly 16:26:01 ack decentralgabe 16:26:04 usenrmae please 16:26:27 decentralgabe: This one is using @vocab to catch all as undefined terms. 16:27:03 q+ 16:27:21 Orie: The first poll said we include a vocab with base context. It didn't describe how that would be used to assign terms. This poll uses URNs. The next poll will use URL. This one is using one context. We're tlaking about how that context property will assign terms to how it will be used 16:27:31 I will need to drop in a few minutes 16:27:39 ack ChristopherA_ 16:27:52 The other proposal I had queued: PROPOSAL: The base IRI will be a URL. 16:27:59 feel free to run it in my absensence. 16:28:04 https://auth0.com/blog/url-uri-urn-differences/ 16:28:15 All the polls in special topic call are non binding. 16:28:46 ChristopherA_: In general in favour of URNS because it is broader. Can use hash based or other kidns of references / not just Web. Has some potential security advantages but that's not what I'm hearing re URN vs URL. Is there some intent form your design to leverage the benefits.. Are there security dis/advantages? 16:29:38 Orie: If URL, you're inviting someone ot run it at a location / host. A lot of times whne you click, they don't necessarily resolve. You can use URN to get around that. Bnoth uniquely identify a term. One requires a host server and potentially have complains. THe other one just give a unique name 16:29:41 ack dlongley 16:29:41 dlongley, you wanted to explain @vocab quickly 16:29:49 URN also signals that there might be standardization or other conformance requirements around the URN 16:29:49 q 16:29:51 q+ 16:30:00 dlongley: @context in JSON_LD just maps JSON keys to make them globally unambigious. 16:30:06 dlongley: You can do that for each term and mix and shar evocabs 16:30:10 Just to point out: a URN may or may not be resolvable. Just because it's a URN does not mean it's not resolvable. 16:30:14 dropping now, good luck :) 16:30:23 dlongley: @vocab in @context... for any key that wasn't explicitly called then prepend this to the URL 16:30:44 q+ 16:30:52 q- later 16:30:53 q- 16:30:55 ack ivan 16:30:58 (in Gordian Envelopes, each node (which could be a node about ontology of a predicate) can be a provable hash. Thus I like URNs in general.) 16:31:17 zakim, close the queue 16:31:17 ok, kristina, the speaker queue is closed 16:31:20 q+ 16:31:35 Dave, that was helpful, but doesn't the @context property of JSON-LD already establish the mapping of all terms to URIs? 16:31:55 drummond: if you specify all terms, yes -- `@vocab` lets you cover terms that aren't specified but still used 16:32:22 and to be clear, `@vocab` goes inside an `@context` value (it's an option you can use to "catch all" otherwise undefined terms) 16:32:23 (kristina, can we get Manu to explain his point in parens above?) 16:32:40 ivan: TO add do dlongley . You use the term catch all. it does that. At the same time, it is dangerous because if I put @vocab at the end, then no one will see I made th emistake. If I use a term because it is wrong. This is a slight danger we shouldn't forget. To follow on Dave, if we put the vocba in the main context, that's still gives the possibility to use more vocab to be added to the header. this is for the simple cases. the processing 16:32:40 is in order. if you have v2 context add another context value then give explicit terms then that will work. that's a catch all. whether it is a URN or URL i see that as a secondary issue. the real issue is which ??? mechanism. 16:32:56 ack David_Waite 16:33:01 (@manu, understood! have a good flight) 16:33:08 I would like to point out -- the increasingly common use of JSON Schemas in VCs, in addition to @context, mitigates the danger Ivan mentioned 16:33:23 `@vocab` is a more blunt instrument for providing term mappings than doing each term => URL mapping individually. 16:33:26 agree dmitriz 16:33:35 David_Waite: The diff re location and one isn't. Names guarantee that wno't be used. 16:33:46 Can vocab & context terms conflict? 16:34:02 Kerri_Lemoie_ not really 16:34:15 @Kerri - not quite conflict. a vocab can point to a different URL than what's encountered in the context, for example. but that's not a conflict 16:34:17 Kerri_Lemoie_: if an individual term mapping is specifically defined in a context, the `@vocab` value will not be used. 16:34:19 kerri - effectively last context wins 16:34:36 Kerri_Lemoie_: `@vocab` is a "fallback". 16:34:51 Got it. Thanks 16:34:51 kristina: The established direction is: first poll that we'll not be running won' tbe running additional proposal on URN/RUL. The group doesn't have enough info to run it yet. Let's run it in the future. 16:34:59 ack brentz 16:34:59 brentz, you wanted to talk about resolutions made on this call 16:35:08 oliver has joined #vcwg-special 16:35:09 zakim, open the queue 16:35:09 ok, kristina, the speaker queue is open 16:35:14 q+ 16:35:15 present+ oliver 16:35:45 RRSAgent, please draft minutes 16:35:45 I have made the request to generate https://www.w3.org/2022/11/29-vcwg-special-minutes.html TallTed 16:35:50 brentz: The first proposal we ran. The response was lukewarm. No -1. We are resolved on that. What that means for the regular group is that we have a 7 day window for people to come back - comment period. After the 7 days / resolution then it is resolved for the group. Just want to clarify that's the process we are running. 16:35:56 RRSAgent, make logs public 16:35:57 Thanks @ivan! 16:36:10 brentz: Everything we ran last time it was just polls not proposals 16:36:21 brentz: With proposal this is a decision the gorup is making now. 16:36:29 @ivan - can you try that link again please? 16:36:30 brentz: As long as the notes reflect that 16:36:38 q+ 16:36:45 scribe+ csarven 16:36:49 @ivan - thanks 16:36:49 RRSAgent, please draft minutes 16:36:49 I have made the request to generate https://www.w3.org/2022/11/29-vcwg-special-minutes.html TallTed 16:37:09 ack selfissued 16:37:19 scribe: csarven 16:37:28 RRSAgent, please draft minutes 16:37:28 I have made the request to generate https://www.w3.org/2022/11/29-vcwg-special-minutes.html TallTed 16:37:53 selfissued: Chris' thread on CBOR made me think about we do want a CBOR representation(s) at some point and that effects the characteristics of the data model. 16:38:01 selfissued: I have 3 proposed polls 16:38:10 q- 16:38:19 selfissued: 1. Whther the group wants to limit itself to JSON only or we want to consider in the future non-JSON representations 16:38:35 selfissued: The first poll is intentionally negatively worded to see if people agree with it.. 16:38:36 Mike's proposed poll #1: VCs must only ever use JSON representations 16:38:50 q+ 16:38:51 does that include JSON-LD? 16:39:01 what are the otherr questions? 16:39:02 q+ 16:39:03 Does that include CBOR-LD? 16:39:04 q+ 16:39:04 json-ld is json :think: 16:39:05 q+ 16:39:08 ack dlongley 16:39:15 dlongley: My concern is the poll being about x for all time. 16:39:24 You can map VCs today to CBOR (via CBOR-LD), losslessly and back. 16:39:27 dlongley: I'd be shocked if anyone would vote since no one knows what the future holds 16:39:27 q+ 16:39:33 ack ivan 16:39:37 dlongley: Limit to length of this groupo's charter 16:39:48 ivan: When you talk about JSON, pure JSON or JSON-LD. it is not something else 16:39:51 So, we already support multiple serializations today if they're *-LD based... same w/ JWTs, you can embed a VC JSON into CWT and secure it that way 16:39:56 selfissued: Both are JSON for the purpose of this poll 16:40:03 ack ChristopherA_ 16:40:18 @Dave - agree with that. something forever is unrealistic. 16:40:21 ChristopherA_: Is there interest in CBOR? 16:40:32 ChristopherA_: If the question before us about vocab and context, was just about JSON. I'd just put 0s. 16:40:37 I expect when YAML-LD becomes a thing, you will be able to losslessly map a VC <-> YAML-LD and back (if we keep @context) 16:41:16 ChristopherA_: If there's a lot of interest in vocab and things of that nature, ... if interest in CBOR then my vote would be different. Makes me hard for me to know if this group eventually wants to in the scope of this charter / ~2 years.. 16:41:42 ChristopherA_: Are the things that I vote on as IE solely about JSON or JSON-LD representations or have some impact in the future e.g., VC3 like compact binary object representation 16:42:03 ack mpororck 16:42:06 mpororck: There are also things like YAML and YAMLLD should bring us to transparent mappings. 16:42:21 mpororck: Creating JSON schema and JSON-LD from that. 16:42:45 mpororck: I'd like to see clean CBOR represesentations and like to see as a legitimate format for VCs. Lessons from v1-2. 16:42:55 my concern with cbor-ld is that it is too tightly tied to json-ld. 16:43:06 mpororck: Let's not limit ourselves to JSON. 16:43:13 mpororck: There are other formats that can be considered here. 16:43:20 I'm not saying doing cbor-ld, but you loose something tying so close. 16:43:24 Mike's revised poll #1: This working group will restrict itself to only work on VCs with JSON representations 16:43:49 q+ 16:43:51 selfissued: Revised to accommodate dlongley's comment on duration of the WG 16:43:52 like that phrasing 16:43:54 q+ 16:43:59 dlongley: yes it does reflect my concern 16:44:05 eeeh, if this is taking us down the same path we went down for DID Core -- -1 16:44:05 ack ivan 16:44:13 if it's a "we should prevent expression of VCs in other serializations" -- +1 16:44:22 s/should/shouldn't/ 16:44:22 ivan: Where do you put the word normatively re proposal. 16:44:40 ivan: the poll as it stands today, per default true per charter. 16:44:56 kristina: i don't see anyhting in the charter limiting to json??? 16:45:06 ivan: it doesnt say for v1 either. it is at least quesitonable 16:45:07 -1 16:45:29 ack TallTed 16:45:48 repeat proposal 16:45:50 TallTed: The location of only communicates what you wan tto communicate. I htink what ou want is this group will restrict itself to only JSON representations 16:46:00 POLL: This working group will restrict itself to work on VCs only with JSON representations 16:46:07 -1 (VC data model supports CBOR-LD and YAML-LD now, so restricting to JSON only is losing functionality) 16:46:07 -1 16:46:10 -1 16:46:10 s/only communicates what/only doesn't communicate what/ 16:46:10 -1 16:46:11 -1 16:46:12 -1 16:46:12 -1 16:46:13 -1 16:46:13 -1 16:46:15 -1 16:46:15 -1 16:46:17 -1 16:46:18 -1 16:46:19 -1 16:46:21 0 16:46:23 0 16:46:34 -1 (already people working on CBOR-LD) 16:46:37 -1 16:46:49 0 16:47:04 kristina: Majority -1. A few 0s. People pointing on existing work on CBOR 16:47:11 Proposal: This working group will restrict itself to work on VCs with only JSON representations 16:47:41 Proposal: This working group will NOT restrict itself to work on VCs with only JSON representations 16:47:46 +1 16:47:48 +1 16:47:49 +1 16:47:50 +1 16:47:51 +1 16:47:51 +1 16:47:51 +1 16:47:53 +1 16:47:53 +1 16:47:56 +1 16:47:57 0 16:47:57 +1 16:47:57 0 16:47:58 +1 16:47:59 +1 16:47:59 +1 16:47:59 +1 16:48:00 +1 16:48:06 +1 16:48:08 q+ 16:48:14 q+ 16:48:16 0 16:48:22 +1 (but the details matter here... don't want an "Abstract Data Model" decision to happen again) 16:48:33 +1 to manu, details really matter here. 16:48:58 +0 16:48:59 q+ 16:49:03 RESOLVED: This working group will NOT restrict itself to work on VCs with only JSON representations 16:49:04 ack selfissued 16:49:06 In short, this is just stating reality right now -- we're already working on mapping VCs to other serializations, so it's a bit of a no-op poll. 16:49:14 ack ChristopherA_ 16:49:19 q+ 16:49:23 ChristopherA_: Am committed to CBOR reprsentation of this and a small community of this that doesn't want JWT or ???-LD. 16:49:45 ChristopherA_: At least tThis group now doesn't want ot prohibit future work on CBOR, e.g., WG on it. 16:50:12 q+ 16:50:15 The best way to achieve other mappings is to probably re-charter the group to work on "Mapping to X serialization" specs. 16:50:34 +1 to manu's point. that's why I voted 0 16:50:38 (like we do for VC-JWT today) 16:50:46 ChristopherA_: Am worried that this is wishy-washy whether our people are committed to working on one of thse formats or wait for others to work on it. There are some advantages ... we're only applying to VCs as expressed in normative way fo rthis and not prohibit future use or standardisation with CBOR. 16:51:04 mapping from JSON to CBOR is within scope, IMO. Making an abstract data model to map to arbitrary serializations would be madness. 16:51:12 q- 16:51:13 kristina: I decided to take up this conversatoin in cases where it'd effect the design choices you are making now 16:51:18 +1 to manu's suggestion to focus working topics. 16:51:20 yes agreed w/ JoeA above ^ 16:51:47 Noting, per our comment on the issue - myself and others at mesur.io will commit to working on CBOR representations of VCs 16:51:48 kristina: whether CBOR would actually be owkred on .. and as you said it'd be the people that decides to or not or shows up. at least now trying to determine if there is enough interest and the decisions that need to be made right now 16:51:51 ack ivan 16:52:03 I just would like this working group to say they will not get in the way of other groups doing CBOR. 16:52:33 +1 @ChristopherA helping map JSON to CBOR is important 16:52:38 Well, it depends on what other groups do -- if they do something that destroys the core data model in some way, that'll be of concern to this group 16:53:01 but if it's something that's complementary, this group would probably be supportive. 16:53:01 ivan: The reason I voted 0 is not because of aversion of CBOR or YAML or what might come up. I'm worried about reminder as a conversatoin athat this group will do work like CBOR and what we achieve is what we've already started which is a lot of owrk. It shouldn't be regarded as a "yes, we will do it" and to not recommendation to the lot 16:53:16 ack dlongley 16:53:18 kristina: It is that this group wouldn't get in the way if those get picked up 16:53:39 This group would need to get in the way if the way the work is picked up is damaging to these specs. 16:53:53 dlongley: I at least we have unanimous support on that proposal. we didn't get into how that will be done or what serializations or who will do it. that's all important. it is not to block. 16:53:54 manu +1 16:53:57 Mike's proposed poll #2: Our data model needs to accommodate non-JSON representations 16:54:17 q? 16:54:19 In that, all of a sudden, we'll have work happening on VCs elsewhere, where this group will not have a say in the outcome -- that's a dangerous precendent to set. 16:54:45 dmitriz: Is the implication that we need an abstract data model like in the DID WG? 16:54:55 I don't understand how poll #2 is different from poll #1 16:55:01 q+ 16:55:02 selfissued: ??? 16:55:04 q+ 16:55:05 i think poll #1 might get some -1s 16:55:09 poll #2 i mean 16:55:15 +1 manu, what /is/ the difference from the preious poll? 16:55:27 selfissued: The way the spec is written it presents JSON and some as JSON-LD 16:55:31 Oh, no way, -1 to abstract data model -- never again! :P 16:55:38 selfissued: We need to at least generalise the language so that other mappings are possible 16:55:50 selfissued: Not minimising the workload but to plan or anticiapte tha twokr 16:55:51 i'm not ready yet to say we have to generalize yet vs. doing mappings to JSON so i will be -1 to this 16:56:07 manu, does that mean a CBOR based VC can't do label property graphs rather than @context? 16:56:13 q+ to say we need a primary JSON representation that supports mapping, not multiple representations 16:56:16 selfissued: not touching the abstract data model word because some people have negative / positive reactions in the group. interested in results oriented the way it is worded 16:56:24