21:50:06 RRSAgent has joined #vcwg-special 21:50:10 logging to https://www.w3.org/2023/04/25-vcwg-special-irc 21:52:54 brent has changed the topic to: Meeting Agenda 2023-04-25: https://www.w3.org/events/meetings/9ff74350-6398-41c5-a5d3-11cd54558218/20230425T180000 21:53:08 zakim, start meeting 21:53:08 RRSAgent, make logs Public 21:53:10 please title this meeting ("meeting: ..."), brent 21:53:19 meeting: VCWG Special Topic Call 21:53:28 Chair: Brent Zundel 21:53:36 present+ 22:00:54 mprorock has joined #vcwg-special 22:02:01 JoeAndrieu has joined #vcwg-special 22:02:22 decentralgabe has joined #vcwg-special 22:02:28 present+ 22:03:15 Phil_L has joined #vcwg-special 22:03:17 present+ 22:03:34 scribe+ 22:03:52 present+ 22:03:52 present+ 22:04:41 brent: topic for today - "what is the relationship b/w the VCDM and terms defined there and the vocabulary document" 22:05:01 present+ 22:05:15 ... partly us getting on the same page, partly what do we need to say normatively about this relationship...in response to a series of PRs @Orie raised 22:05:34 ... Orie please talk us through your staging of this topic 22:06:14 present+ 22:06:18 Orie: raised after reserved properties table. talked about wanting to reserve *things* but if no consensus, we should enable them to be reserved for exploration. not defined normatively 22:06:31 smccown has joined #vcwg-special 22:06:42 ... have heard that Manu's interpretation does not align with that. 22:06:55 selfissued has joined #vcwg-special 22:07:02 present+ 22:07:10 ... we have the core data model which defines terminology and how to use them. we have a vocabulary which reflects in linked data building blocks those terms we use 22:07:54 ... vocabulary term definitions always have "2018" in them like XML always has 1999 ... we have LD contexts which have URLs with normative requirements, but not the value of the object that's dereferenced 22:08:20 ... important for implementers to be able to read the technical recommendation and have all necessary guidance to impl the rec 22:09:09 ... we can put additional properties in, like today including RDF...in v1 were some complaints about this. now people had moved to using separate contexts 22:09:41 ... because of the structure of the new Data Integrity proof format we're trying to avoid creating separate contexts for suites. have evolved to where we are today. PRs related to the table PR that establishes these terms as reserved 22:09:52 ... human readable piece may change, but the URL won't 22:10:36 ... main concern I have: we've inherited a lot of compromised from v1 where we can't make any changes. would like to make a cleaner spec, vocab, context. opportunity to do that 22:11:27 ... and leave room for the VC specs directory to do its job. about finding the right balance. this will be intuitive to developers and convey extension data we want. if we do a bad job developers will be confused and/or biased towards one securing format over another 22:11:40 ... we've split the specs but not the data model to reflect that 22:11:58 Orie has joined #vcwg-special 22:12:01 present+ 22:12:06 q? 22:12:18 brent: want everyone on the same page to what the perceived problem is. Orie has pointed out an ideal state. is that something others agree/disagree with? why? 22:12:19 q+ 22:12:48 q+ manu 22:12:59 ack dlongley 22:13:45 dlongley: bits of what Orie said I agree with, others we need to explore further. agree w/goals of making things cleaner in the 2.0 work where we can. have been doing that (e.g. multiple context for suites that are used) 22:13:56 +1 to making things cleaner in 2.0 22:14:52 ... also prioritizing end users and making compromises that may not match with ideological purity but going for usability. we have made a number of compromises already in how 2.0 works, like adding @vocab. a big component to understand. added to make sure people who are adding new contexts can do it more iteratively - more freedom to make mistakes 22:15:31 FTR https://www.w3.org/TR/design-principles/#priority-of-constituencies 22:15:40 ... need to be more careful around being consistent in helping users out. make sure the definitions they're winding up with are the right definitions. don't want to lose @vocab benefits or create additional confusion 22:16:10 ... more contexts = more chances for term definition mismatch. already favoring common case. need to be careful doing that or we'll be sending a mixed message on our design 22:16:19 ack manu 22:16:30 zakim, who is here? 22:16:30 Present: brent, decentralgabe, manu, dlongley, JoeAndrieu, Phil_L, dlehn, selfissued, Orie 22:16:33 On IRC I see Orie, selfissued, smccown, Phil_L, decentralgabe, JoeAndrieu, mprorock, RRSAgent, Zakim, brent, TallTed, csarven, cel, dlehn, dlongley, stenr, shigeya 22:16:40 present+ manu 22:16:58 present+ mprorock 22:17:03 manu: regarding these PRs, very strong -1 on them. primarily: it makes developers lives worse. trying to get down to 1 context to make developers lives easier. the more that's included by default the easier it's going to be for people to pick things up and start using it 22:17:11 manu has joined #vcwg-special 22:17:38 ... if we're going to remove these properties we should re-open the @vocab discussion. there will be properties that default to the wrong property. big downside. Orie's argument is for academic purity, but we should be prioritizing developers 22:18:09 mprorock_ has joined #vcwg-special 22:18:17 "We are trying to nudge them towards using Data Integrity stuff"... yep. That is what we are doing. 22:18:22 ... if we look at proof, data integrity proof, people are using these properties. have demonstrations of 17+ implementers. one reason to make this change was to remove an additional context they would add in 22:18:24 q+ 22:19:05 Orie: yes, nudging towards "DataIntegrityProof type + cryptosuite property" instead of individual contexts for each suite. 22:19:10 ... anything that results in more work for developers ... if we split things up more in the name of academic purity we're harming developers 22:19:51 ... schema.org has an enormous amount of properties in there, no problems. tons of websites use them. having extra unused properties is not problematic for them at all. works against simplicity 22:19:56 ack decentralgabe 22:20:02 scribe+ 22:20:39 decentralgabe: I didn't really understand it until I heard you say that Manu. Is there a way to segment out core properties in a context vs. others? And have a different section for other properties for data integrity proof, etc.? To make it clearer so the distinction is clear? 22:20:43 Yes, data integrity already ships a separate context for DataIntegrityProof. https://github.com/w3c/vc-data-model/pull/1091#issuecomment-1514806914 22:20:58 decentralgabe: I agree that if this makes it easier on developers to have one context we should do that if it's clear that's the case. 22:21:06 scribe+ 22:21:13 q+ 22:21:32 scribe- 22:21:33 q+ 22:21:41 manu: have heard it makes developers lives difficult if there are extra properties in the base context. has not been demonstrated that that is true at all 22:22:43 ... does having an extra property or two really make developers lives harder? have a lot of data with schema.org to the contrary. why is this a burden to devs? 22:22:53 q+ 22:23:18 q- 22:23:33 brent: has the problem been laid out clearly? where to go from here? 22:23:51 brentz has joined #vcwg-special 22:23:58 q? 22:23:58 +1 selfissued 22:24:00 q+ 22:24:02 ack selfissued 22:24:13 selfissued: there is an "integrity for the work argument" that stuff in the context should be equivalent to what's in the VCDM spec, no more, no less. we shouldn't have speculative/optional stuff in there. in particular the proof property is optional for many of the VCs and shouldn't be there 22:24:17 q+ manu 22:24:21 ack Orie 22:24:57 Orie: Manu is asking the right question regarding, "what is the real burden for developers?" I would like to try and answer part of it. comparison to schema.org is correct...it is a giant kitchen sink has lots of adoption 22:26:03 ... meant to define a singular vocabulary in a single vertical / industry domain. it is a thing that does impact developers. first impact is developers looking at it - if its long, its long to read and takes a long time to make sense of it 22:26:17 I joined a few minutes late. Which PRs are we discussing? 22:26:55 ... aware of what's in it and what to do with it. if developers aren't doing anything with the context, they don't need to understand it. so what's the value of the context? what's the dev ex? 22:27:25 q? 22:27:28 q+ 22:27:33 ... JSON-LD context is applied during transforming from JSON-LD to n quads. also applied if you're ingesting a VC into a graph DB or if you look at term defns in our vocabulary 22:27:58 ... in v1 main complaint was "I can't make a new data integrity proof suite since it's not shipped in the default context, so I have to add another and now there are term collisions..." 22:28:21 ... if you're a developer and debugging an implementation you will be reviewing the content in a JSON-LD context to make sense of that 22:28:55 ... not a burden to devs if everything works properly (both in impl and spec). 22:30:05 ... JSON LD is part of the cost for signing and verifying. not a high cost if the cred is small and context are small. if cred is really large and context is small...ok, want to look at how is the context shaping these N-Quads. are they vocab terms or "properly defined terms" 22:30:27 ... now we just call them automatically mapped terms. still confused - what's the expectation for WG members regarding knowledge of JSON-LD 22:30:53 ... if they don't need to know what the context is at all, and it doesn't impact them. then why is it required in the way that it is? 22:30:57 q+ 22:32:00 ... made it so we have to add a second context to add support for key types. could be other properties we choose to add to the reserved properties table. let's give ourselves a clean slate and add pieces we have consensus on 22:32:24 ... if we can't get consensus, add it as an extension to the VC specs directory. better than keeping context remnants from the first version 22:32:46 ack dlongley 22:33:52 dlongley: as a developer had a hard time finding where I'd have pain. context is already short. don't worry about it much. happier as a dev to work with a single context if I can. many devs are aware of this and have talked about it. wanted to reduce the number of contexts. also happier as a dev to reduce term conflicts. 22:34:28 ... want to encourage experiments without breaking experimenting...these are all benefits and outweigh anything that seems like it doesn't really bother many developers. can't make out what the problem would be 22:35:02 ack manu 22:35:43 manu: 2 things. first: to address selfissued comment about proof being in a different spec so let's split it out....there are a lot of impls, last JFF plugfest, 17! broadly used in the ecosystem. the reason we have a base context is to make it useful for broad swaths of the ecosystem 22:36:28 ... items that we add in the context, not finding the arguments that this is hard for developers compelling. by and large in the implementation community nobody has said "the base context is too big". 22:36:44 ... the reason we have proof in the base context is because it's helpful 22:37:31 "evidence" is also in there: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L32 22:37:36 mprorock - how are you defining 'independent developers'? 22:37:39 ... not finding the arguments that this is a problem compelling. Orie hear that there's a grab bag of problems. To Mike's point: proof and data integrity are in there because of broad usage. Other arguments Orie...having a hard time 22:38:06 ... some people speaking against it aren't even familiar with JSON-LD or its usage. not convincing this is a huge burden 22:38:14 q+ 22:38:23 ... not seeing the problem 22:38:28 ack mprorock_ 22:39:20 mprorock_: maybe this is a concrete proposal. to me dev friendly/not is beyond the point. not sure that schema.org is a good comparison since it falls into one of two buckets: describing a standard (limited to things in the standard) or broadly capturing existing patterns of usage on the web 22:40:46 q+ to say that the context helps differentiate vocabs through mapping, it doesn't do the things that are being said here 22:40:50 ... in this case we have a standard we're developing for core use. it clashes with me to have something present, and not flagged as an extension point, to exist in here. concerning to me to see these things in a context. I would say if it normatively exists in the data model then it exists in the core context. edge case is reserved terms 22:41:03 q+ 22:41:13 ... reserved terms are a separate issue. may drop proof, evidence, etc. back in. need to handle them in a way to signify they're handled elsewhere 22:41:15 scribe+ 22:41:15 ack decentralgabe 22:41:43 decentralgabe: better understanding now - issues with json-ld bubbling up into the core data mode 22:42:15 ... i would rather not have to worry about contexts at all - don't think the best way to handle the issue is to try and get everything in the core data model context 22:42:17 q+ if we are going to go multiple contexts, we'll have to re-open the @vocab discussion. 22:42:22 q+ to note that if we are going to go multiple contexts, we'll have to re-open the @vocab discussion. 22:42:25 ... a fan of multiple contexts in this case 22:42:27 ack Orie 22:42:29 https://github.com/w3c/vc-data-integrity/blob/main/contexts/data-integrity/v1 22:43:48 Orie: arguing against myself...agree with making data integrity proofs as easy as possible for devs. in the past we've included terms in the core context to avoid developer complexity. if you have @vocab you just have one context and can do data integrity proofs now. automatically mapped and data integrity proof benefits 22:44:36 ... there is another case where I'd use this: places where you need a data integrity proof, not a cred. sometimes you need to sign an object (OCAP, DID Document, mastodon profile) and the object is not a VC. can use a data integrity context to add support 22:44:55 Phil_L_wonders isn't one of the reasons the @context is more flexible than just defining things in the core data model precisely to encourage experimentation, niche uses, or emerging properties? 22:45:19 ... allows for you to secure these data models... there is an open issue for why does data integrity proof have a second context if the credentials v2 context defines the same terms? 22:45:23 brentz: 10 min left! 22:45:25 ack dlongley 22:45:25 dlongley, you wanted to say that the context helps differentiate vocabs through mapping, it doesn't do the things that are being said here 22:46:24 why not have data integrity context define a base context to the core data model - boom - one context 22:46:32 dlongley: got on the queue to say context helps global disambiguation--what terms are. that's what we're interested in doing. important and useful even if terms don't have anything behind them (for experimentation). to respond to Orie: why is there another context for data integrity? reason is so you can use it if you're not using a VC 22:46:57 ack manu 22:46:57 manu, you wanted to note that if we are going to go multiple contexts, we'll have to re-open the @vocab discussion. 22:47:02 ... there is not a default context in that space, you can use either one. if using VCs you can use the VC context, if data integrity...that context 22:47:20 manu: the use case there is for activity pub. looking at extensions to VCs 22:47:36 "description": { 22:47:36 "@id": "https://schema.org/description" 22:47:36 }, 22:48:11 ... other point here: well the base v2 should only have terms in the core data model ... we already have schema.org in the core data model since people asked for them in 1.0 and 1.1. Tobias @ MATTR, and others said it would be nice to have names/descriptions in the base context 22:48:19 contexts are multi-vocab. 22:48:23 ... an example of things in the base context that are helpful for developers 22:48:57 +1 to manu ... contexts are not "documentation" 22:48:58 ... the base context is there to help developers. pulls in terms that are frequently used. as the group continues to work and toward 3.0 we will pull things into the base context. not meant to only be reflective of the VCDM full stop 22:49:04 +1 to manu, contexts are for developers. 22:49:09 q+ 22:49:11 ... people's mental models of the base contexts are off based on prior consensus of the group 22:49:22 ack dlongley 22:49:37 dlongley: put in chat but want to say +1 to Manu. contexts are not documentation, they are there to help developers. having these mappings is helpful to developers 22:49:59 q+ 22:49:59 ack Orie 22:50:06 brentz: where to go next? 22:50:44 Orie: better guidance in the spec regarding JSON-LD and the context values. current spec pastes the JSON-LD context directly into the spec. see terms we're intending to reserve in the core context. the reserve table discussion needs to be squared with the JSON LD context 22:51:02 +1 to give better guidance in the spec and, IMO, close the PRs to remove terms from the contexts 22:51:17 ... I would be supportive of making the context object normative if it is helpful to developers and they need to use it to produce data integrity proofs. why do we make the URL normative but don't talk about the value behind it normative? 22:51:18 +1 orie - if the core data model is a JSON-LD data model, then we need a normative context 22:51:31 ... on that thread, where are we missing normative guidance for devs? 22:51:31 q+ to +1 to better guidance, note that we might want to remove copy-paste JSON-LD Context out of spec... unclear about normative JSON-LD Context. 22:51:54 ... is it a mistake we mandate a specific URL because that prevents inlining of the @context. maybe better to make it normative 22:52:08 ack manu 22:52:08 manu, you wanted to +1 to better guidance, note that we might want to remove copy-paste JSON-LD Context out of spec... unclear about normative JSON-LD Context. 22:52:16 and re name and description, there is an easy fix - an addition that you MAY have name or description in a VC per the core data model 22:53:02 is the context normative? 22:53:12 manu: +1 to better guidance. I don't know exactly what that could be. personally I never liked the fact that the entire context is in the spec. done when we felt we needed to do it. towards the end of the CR process people got scared - what if we had to fix a bug in the context. let's make it non-normative so we can update and fix it 22:53:32 ... today I don't believe the context is normative. it's in the appendix and hashed. non-normative to give it flexibility to fix bugs 22:53:34 q+ 22:54:15 manu: against making the JSON-LD context normative. feels heavy handed. don't know what we accomplish by doing it. unsaid agreement in the group: let's be very careful with the context since we know it'll break impls. have been good for 7 years - don't see that changing 22:54:29 context being "non-normative" is a process issue ... maybe evergreen would fix this :) 22:54:39 ... would like to avoid developer concerns Orie spoke to - come across a giant context and think it's complicated. let's remove it from the spec 22:54:56 ... vocab document is non-normative and just reflects what's in the core spec and we can refer to it by hash 22:55:03 I don't see how we can say "URLs for terms is what we are here to do", and also "a non normative object is how you get them". 22:55:45 ... can say -- base context is not purely a reflection of the core data model, it's there to help devs. e.g. added name and description from schema.org, since folks asked for it and deemed it useful 22:56:04 q? 22:56:06 ... +1 to sections like that to elaborate on design decisions and how we're trying to serve developers 22:56:09 ack Orie 22:56:32 Orie: like what Dave said: "we're here to give URLs to terms" - that's the entire point of LD as a core representation. like Manu's comment on giving guidance 22:56:44 q+ 22:56:52 I'm sympathetic to Orie's position around making the context normative, just worried about process issues. 22:57:05 we say you must have a context 22:57:27 if so, then i get nervous if there is not a baseline normative context that is built off of 22:57:27 ... question is on the normative work we're here to do. this object is the only way for verifiable credentials. what is it we mean by normative? I think: you must understand this to implement the spec. seems like the object needs to be normative or explanation for why you don't need to understand it. should focus on better guidance 22:57:29 ack manu 22:58:00 manu: agree with Orie. maybe what we need to do is list all URLs. by this property we mean this URL...context has to line up with that. worried about a normative context. 22:58:12 +1 manu - this could be bandled spec side as well by defining what a normative context looks like 22:58:16 ... if we define all URLs we could be done 22:58:29 brentz: thanks all good conversation 22:58:47 zakim, end the meeting 22:58:47 As of this point the attendees have been brent, decentralgabe, manu, dlongley, JoeAndrieu, Phil_L, dlehn, selfissued, Orie, mprorock 22:58:49 RRSAgent, please draft minutes 22:58:51 I have made the request to generate https://www.w3.org/2023/04/25-vcwg-special-minutes.html Zakim 22:58:58 I am happy to have been of service, brentz; please remember to excuse RRSAgent. Goodbye 22:58:58 Zakim has left #vcwg-special 22:58:58 rrsagent, bye 22:58:58 I see no action items