14:41:52 RRSAgent has joined #vcwg-special 14:41:56 logging to https://www.w3.org/2023/04/18-vcwg-special-irc 14:41:56 RRSAgent, make logs Public 14:42:27 please title this meeting ("meeting: ..."), ivan 14:42:27 Meeting: Verifiable Credentials Working Group Special Topic Call on open reserved properties 14:42:27 Date: 2023-04-18 14:42:27 chair: kristina 14:42:27 Agenda: https://www.w3.org/events/meetings/e88d30bd-4099-49d1-b769-1d8cd39a1b28/20230418T110000 14:42:27 ivan has changed the topic to: Meeting Agenda 2023-04-18: https://www.w3.org/events/meetings/e88d30bd-4099-49d1-b769-1d8cd39a1b28/20230418T110000 14:53:57 brent has joined #vcwg-special 14:59:14 present+ brent 14:59:14 present+ 14:59:35 mprorock has joined #vcwg-special 15:00:27 present+ 15:01:40 present+ orie 15:01:44 hsano_ has joined #vcwg-special 15:01:47 present+ hiroyuki 15:02:01 present+ tallted, davidc 15:02:06 present+ manu 15:02:26 present+ dlongley 15:03:59 Orie has joined #vcwg-special 15:04:43 DavidC has joined #vcwg-special 15:04:50 present+ hsano 15:04:51 present+ 15:04:53 present+ 15:04:53 scribe+ 15:05:11 cabernet has joined #vcwg-special 15:05:25 present+ 15:05:25 Topic: PR 1082 15:05:29 Topic: https://github.com/w3c/vc-data-model/pull/1082 15:05:44 present+ natran, cabernet 15:05:50 brent: this pr was raised by manu, everyone seems to be in favor of the general idea 15:05:59 q+ to provide some background on the PR. 15:06:02 ... my hope was to discuss proposals for adjustments to it 15:06:13 q+ 15:06:20 ack manu 15:06:20 manu, you wanted to provide some background on the PR. 15:06:32 scribe+ manu 15:06:33 gnatran has joined #vcwg-special 15:06:36 manu: some background, we have other PRs that are "stuck" 15:06:59 ... they are all trying to add new properties to the Verifiable Credential RDF class in the vc data model 15:07:27 ... there has been discussion on too much work, and maybe we should not add more work / other items 15:07:35 ... "what work should we take on" 15:07:46 ... "what should we delay to a future working group" 15:08:10 ... the reason for the PR, is there a way for the group to signal, there is interest in these properties, we want to reserve them 15:08:34 ... we might want to address things in the past or future, but the working group doesn't want to say anything normative about them 15:08:57 ... the PR is a way to signal that properties are important, but we are not going to say more about them 15:09:27 ... seems people are in favor of saying something, we don't know what goes in the table 15:09:38 ... so that seems to be holding things up 15:09:58 scribe+ 15:09:59 brent: that is pretty close, but i got other feedback 15:11:37 q+ to add my 2 cents 15:11:41 ack Orie 15:11:44 Orie: I agree with what Manu said, we need something like this PR, I'm glad Manu is saying there are no normative requirements. The thing I'd like clarity on is: some of these properties have existing language in the spec, and our spec has staetments about these properties, if we reserve them and put them in the table, what requirements are on the implementer? What are we reserving, a JSON member, a JSON Member and an IRI, or a name a JSOn member 15:11:44 and it's presence in the JSON-LD Context? What is the impact on implementers on reading v2 of the spec. Clarify relationship between this table and VC Specs directory, we could run proposals to get clean consensus. 15:12:14 q+ 15:12:23 ack brent 15:12:23 brent, you wanted to add my 2 cents 15:12:25 q+ to ask "how are the vc specs dir categories created"? 15:12:28 brent: chair hat off, i read the PR, I like the direction... but the main points I have concern with are, if there is a table like this, there should be some normative guidance related to it, what should an implementer do 15:12:40 q+ on "JSON keywords" 15:12:54 ... I wanted to clarify if this PR is just reserving JSON key words, or also IRIs, context. stuff 15:12:58 q+ 15:13:07 ... my feeling is that properties should be in the table or in the spec... not both. 15:13:14 ... I have proposed some changes 15:13:20 ack ivan 15:13:50 ivan: my 2 cents, ories questions should be answered, we should reserve. both json members and URIs, I am neutral on the context. 15:13:58 ... implementers should essentially do nothing 15:14:11 ... other than not use these terms without the URIs 15:14:23 ... implementers should avoid the terms 15:14:35 +1 to ivan 15:14:37 ack manu 15:14:37 manu, you wanted to ask "how are the vc specs dir categories created"? and to comment on "JSON keywords" 15:14:42 q+ 15:14:55 manu: with editor hat on, we have vc-specs-dir with categories 15:14:59 https://w3c.github.io/vc-specs-dir/#property-based-extensions 15:15:17 ... property based extensions, supports credentialStatus, credentialSchema, termsOfUse 15:15:22 ... where did these come from 15:15:33 ... traditionally they came from the VC Data Model 15:16:01 ... editor hat on, I am trying to figure out what compels the editor of the vc specs dir, to create new categories 15:16:21 ... the core data model should provide this guidance to the vc specs dir 15:16:54 ... editor hat off, I thought it might help to walk people through how we could use the mechanism 15:17:03 ... lets look at render / renderHint property 15:17:23 ... one way we could address it, multiple organizations want to do something and there is a RWoT paper for it 15:17:39 ... lets reserve the term, and say "the wg might do stuff with this term later" 15:17:56 ... then the rendering people can work on it in the CCG, as an extension point the VCWG has defined 15:18:02 ... we can of course do that anyway 15:18:12 ... since JSON-LD is open world model 15:18:29 ... wouldn't it be nice if everyone agreed to how to manager extension points? 15:18:38 ... render goes in the table reserved properties 15:18:52 ... work happens in the CCG, using the vocab defined in the VCWG 15:19:12 ack mprorock 15:19:13 ... this would let us move other extension points out of the working group, and to the community group 15:19:31 dmitriz has joined #vcwg-special 15:19:32 mprorock: I like brent's additions, I would accept the PR with those changes 15:19:43 ... I think it is ok to tack stuff in for an editors draft 15:19:45 present+ dmitriz 15:19:57 ... if things are well defined, we can remove them from the reserved list 15:20:16 ... lets get a base line, and let the community do the rest, non normatively 15:20:17 q+ 15:20:31 q+ to suggest that any property that isn't normatively defined by CR should be in the table 15:20:32 ... lets use do cleanup to the core spec, which needs to be done 15:20:33 q+ to not "SHOULD NOT use extension points" is problematic... 'cause we're putting those in there so that people use the extension points. :) 15:20:36 ack DavidC 15:20:45 cel has joined #vcwg-special 15:20:49 present+ 15:20:59 DavidC: I think there is a difference between extension points already defined, and new ones that have never been written in the data model 15:21:23 ... especially regarding "stay clear of them", they are already defined, and have been used... so we can't provide guidance to stay clear 15:21:33 q- 15:21:42 ... since they have been defined since v1, and that is totally different from new properties 15:22:00 ack dlongley 15:22:03 ... what about other properties, in what category will "isuee" be reserved 15:22:13 q+ to clarify 15:22:19 q+ 15:22:22 dlongley: we need to be careful doing the wrong thing, telling the CCG not to experiment with these 15:22:41 quoting from the suggestion: "Implementers SHOULD NOT use these reserved terms outside of experimental situations." 15:22:42 ... we want people to work on them, to feed those experiments back to the working group 15:22:53 ... you should expect use of these to be unstable 15:22:54 ack manu 15:22:54 manu, you wanted to not "SHOULD NOT use extension points" is problematic... 'cause we're putting those in there so that people use the extension points. :) 15:23:13 Manu: agree with dlongley, there is just one line that you have added that is problematic 15:23:27 ... you "SHOULD NOT use these" is problematic 15:23:38 ... I agree with mprorocks suggestion 15:23:41 https://github.com/w3c/vc-data-model/pull/1082#discussion_r1170186655 15:24:01 perhaps "use with informed caution" rather than "SHOULD NOT use" 15:24:06 ... we should just say: "we are looking for implementer feedback" and "you can use these extension points". 15:24:23 ... I would support warning people to be careful, and that they are not stable 15:24:38 q? 15:24:45 ... people should be able to rely on the vocabulary term existing, and that its defintion or use might change 15:24:51 ... +1 to Mike's table 15:25:06 ack brent 15:25:06 brent, you wanted to clarify 15:25:10 ... I don't like the normative langauge telling people to avoid using them 15:25:14 q+ 15:25:29 q+ to note that we plan to use them in non-experimental situations :P 15:25:38 brent: implementers should not use these reserved terms outside of experimental situations, I am happy to add additional text to elaborate 15:25:49 ... it is important to say "Don't use them in production" 15:26:11 q+ to giving guidance... 15:26:12 ... they are "experimental" we can't let people just do whatever they want with "reserved stuff". 15:26:17 ... I am not attached to specific language 15:26:30 +1 brent 15:26:33 ... we all seem to agree in principle, lets get some language 15:26:33 ack mprorock 15:26:42 mprorock: we do need clear normative guidance 15:26:54 ... you can't assume people will use these things 15:27:09 ... they are fine for development, but they should remain cautioned until they are defined 15:27:43 q+ on timelines. 15:27:44 ... I would be happy to add additional words of caution, regarding incubation, testing and interperability, and you should be aware there is not normative guidance for implementers at this time 15:27:52 q? 15:27:54 ... people need to be aware of guidance 15:27:55 ack ivan 15:28:06 q+ to ask language "Implementer MAY use these properties, but SHOULD expect these terms to change as the process to normatively specify them proceeds." 15:28:16 ivan: as an editor of the formal vocab document... I would like to here answers to ories question from Manu and others 15:28:31 ... does introducing a member to the table mean introducing a URL? 15:28:49 ... the script will need to be aware of "reserved properties" in ontologies 15:28:52 "if you use these in production, you accept the risk that new versions of the VCDM could be incompatible with your usage" 15:29:01 ... will the URL also be reserved? 15:29:03 ack manu 15:29:03 manu, you wanted to note that we plan to use them in non-experimental situations :P and to giving guidance... and to comment on timelines. 15:29:19 Manu: yes, it goes in the vocab... I also prefer to have it in the context 15:29:20 q+ to answer ivan with my preference 15:29:58 ... I wanted to address Brent's comment, I agree with your proposed langauge 15:30:07 q+ 15:30:29 q? 15:30:33 q+ 15:30:37 ... don't ship this to production language is concerning, the working group will end, and then maintence mode, and maybe 4 years from now 15:30:52 ... its highly problematic to reserve something for experimentation for 4 years 15:31:15 ... for render, we do intend to ship to production before the 4 year timeline 15:31:25 ... maybe we can point to vc-specs-dir? 15:31:42 ... it does not mean that it might change, the production use could be broken 15:32:15 ... the guidance should be, VCWG has identified useful properties for experiments and pilots, and it is ok to go to production, but be aware the WG may change the meaning of the property in the future 15:32:29 ... based on the table we see today, I can't imagine us making changes 15:32:34 ... the nuance is important 15:32:48 q? 15:32:48 ... we should let people use them in production 15:32:57 ack brent 15:32:57 brent, you wanted to ask language "Implementer MAY use these properties, but SHOULD expect these terms to change as the process to normatively specify them proceeds." 15:33:23 brent: can other comment on the suggested changes related to the meaning of the terms? 15:33:31 ... would the swap be. fine? 15:33:42 should expect -> MAY expect 15:33:43 "Implementer MAY use these properties, but SHOULD expect these terms to change as the process to normatively specify them proceeds. Implementers SHOULD NOT implement without a publicly disclosed specification describing their implementation." 15:33:44 s/be. fine/be fine/ 15:33:47 +1 to brent's update 15:33:57 ack mprorock 15:33:57 mprorock, you wanted to answer ivan with my preference 15:34:05 mprorock: I wanted to answer Ivan's question 15:34:24 ... I have also added a new suggested text, and I added specification requried to it 15:34:45 ... I play around with evidence, is different from I have a spec that people are using 15:35:15 ... I think clear normative guidance is important 15:35:49 ... should they be in vocab? yes. Should they be in the context? I don't have preference 15:36:04 ack DavidC 15:36:35 DavidC: I think we should clarify difference between extension points with Type and reserved terms 15:36:48 ack ivan 15:36:49 ... for example issuee, is a property 15:37:03 ivan: reacting to what david says, I am wonderign what you mean by type 15:37:11 ... type has a specific meaning 15:37:46 ... reacting to what Manu said, the 4 year delay thing... when we end the WG and plan for maintence, we have the right to declare that this document is "living standard" 15:37:55 q+ on extension points have types... "type": "TheRdfClass" -- also, evergreen was -1'd last time we brought it up :) 15:38:03 ... which means the maintenance WG can add normative changes 15:38:15 ... these extension points could be added here 15:38:27 ack manu 15:38:27 manu, you wanted to comment on extension points have types... "type": "TheRdfClass" -- also, evergreen was -1'd last time we brought it up :) 15:38:36 manu: I like evergreen, but other don't 15:38:55 ... the argument against evergreen, is that the smaller group can modify large normative sections of the spec 15:39:11 ... we can try it again, maybe the group has more trust now 15:39:26 ... regarding what david teams by type 15:39:48 ... I think he means "@type" aliased to "type" and with a value of an RDF class. 15:40:00 correct 15:40:11 +1 to requiring a type for the extension points 15:40:14 ... it would be normative guidance to add the "type" requirement, and decentralized extensibility is supported by type 15:40:21 (for the values of the extension points) 15:40:23 ... can we run proposals? 15:41:02 ... the working group desires a reserved properties table, the second one could start with the values mprorock has provided 15:41:23 q? 15:41:23 q+ 15:41:25 ... the third one could be on guidance for implementers regarding reserved status 15:41:32 q+ to run proposals 15:41:46 ... encouraging people to use them, but with caution, that they might change in the future 15:41:48 q+ 15:41:52 for people reading JSON i think we're suggesting that types are required like this: `"extensionPoint": {"type": "MustDefineThis", ...}` or `"extensionPoint": [{"type": "MustDefineThis", ...}, ...]` 15:41:57 ack ivan 15:42:18 ivan: DavidC has convinced me, that we have to put these entries in the context 15:42:25 ... because of @vocab 15:42:52 ... if the term has a URL in the vocabulary, then we MUST put it in the context file, or the vocab will destroy the consistency 15:42:53 +1 to Ivan 15:42:53 +1 to Ivan 15:42:58 ack Orie 15:44:46 q+ 15:45:14 q+ 15:45:22 ack brent 15:45:22 brent, you wanted to run proposals 15:45:23 Orie: Similar thing to what Ivan said, guidance around warning that term definition would change is equivalent to what term definition would be to be expanded by vocabulary. If any term is not defined in context, it's defined in way that issuer intended it to be defined, if issuer doesn't know, then vocab expansion for that term is correct. It's not with a reserved property for what evidence is... semantic confusion around risk of URL changing 15:45:23 would be and also find it concerning to add terms to core context since it's non-normative, experimental context don't need to be added to normative document and shouldn't harm implementers perspective... in general supportive of reserving things and experiment, not supportive of being in core spec and blending w/ normative terms, normative requirements, non-normative, and no guarantee of consistency and no guarantee that term will change in the 15:45:24 future, future WGs change definition, putting it in context is saying it won't change, that's the issue. 15:45:53 +1 brent 15:45:57 +1 brent 15:45:57 brent: the reason I suggested the changes I did, I think we can address the context issues in seperate PR 15:46:01 q- 15:46:01 q+ 15:46:02 +1 to brent 15:46:31 are these reserved terms or reserved extensions points? they are different 15:46:57 maybe we want to call them unstable or prospective terms? ... since "reserved" isn't quite right per our conversation 15:47:31 PROPOSAL: the VCWG would like to add a table of reserved properties to the VC Data Model 15:47:33 +1 15:47:34 DavidC: I want a seperate table 15:47:35 +1 15:47:36 +1 15:47:38 +1 15:47:38 +1 15:47:38 0 15:47:39 -.001 15:47:47 +1 15:47:48 +1 15:47:53 +1 15:48:34 DavidC: it seems unclear, I am not sure what it means 15:48:35 0 15:48:38 RESOLVED: the VCWG would like to add a table of reserved properties to the VC Data Model 15:48:48 brent: will you object formally? 15:49:15 manu: I will prepare the seperate proposal 15:49:28 recommends we use "prospective" terms instead of "reserved" to encourage incubation vs. discourage it. 15:50:16 -1 15:50:34 want "confirmationMethod" to say "confidenceMethod" ... or leave it off for now 15:50:46 DavidC: it seems it is trying to do too much at once 15:51:03 ... we need to define things, with resolutions, before we can list them 15:51:10 q? 15:51:22 ack DavidC 15:51:24 brent: anything else? 15:51:28 ack Orie 15:51:32 q+ 15:51:59 dmitriz_ has joined #vcwg-special 15:52:18 then we should call the table "extension points" 15:52:43 Orie: Warning of terms in existing context -- brent, you said you wanted to separate context conversation from term conversation, WG needs to be aware that v2 context contains these terms. The correct thing to say here is, if you want to separate the conversations, v2 context already contains, we need to resolve removing terms from v2 context. To make table more concrete, modified version of table currently defined in core context and removing 15:52:43 terms would be a good starting point. 15:52:50 +1 to dlongley's suggestion on confirmation vs. confidence method. 15:52:54 q? 15:52:57 ack ivan 15:53:02 q+ to end the meeting 15:53:14 ivan: i disagree with orie, the context is just a mapping 15:53:22 ... it is not the "core thing" 15:53:43 ... if we agreed, that these terms have a URL in the vocab, the context is the right thing too do 15:53:48 I also disagree w/ Orie's statements about using `@vocab` to establish these terms, and removing things like evidence, and termsOfUse, from the v2 context. 15:53:52 -1 to removing from the core context, these prospective terms should NOT be "issuer defined" via `@vocab`, they should be treated as terms that will be defined by a future WG, that's the whole point. 15:53:53 +1 to Ivan 15:53:55 note, my suggestions says: "Reserved Property" - these are JSON properties 15:53:56 ... otherwise people might just use the JSON term 15:53:59 ... without the URL 15:54:05 ... the context is just a mapping 15:54:06 q+ 15:54:25 ... I don't understand what you mean, by "extension" point 15:54:40 ... we are talking about "Classes" or "Properties" 15:54:43 ack brent 15:54:43 brent, you wanted to end the meeting 15:54:55 brent: we need to end the meeting 15:54:57 an extension point is a subclass of a json term 15:55:04 ... this specific PR seems to have general favor 15:55:13 ... for parts 15:55:25 ... and we should raise issues for extension points vs terms 15:55:34 and vocabulary and context 15:55:35 DavidC, I still do not understand. Json term does not have a subclass... 15:55:53 Orie: I'll file issues and leave comments. 15:56:11 rrsagent, draft minutes 15:56:12 I have made the request to generate https://www.w3.org/2023/04/18-vcwg-special-minutes.html ivan 15:56:19 conceptually it may have as there can be different types of json terms 15:56:24 zakim, end meeting 15:56:24 As of this point the attendees have been brent, ivan, mprorock, orie, hiroyuki, tallted, davidc, manu, dlongley, hsano, cabernet, natran, dmitriz, cel 15:56:26 RRSAgent, please draft minutes 15:56:27 I have made the request to generate https://www.w3.org/2023/04/18-vcwg-special-minutes.html Zakim 15:56:33 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 15:56:33 Zakim has left #vcwg-special 15:57:30 ivan: i believe DavidC is referring to the range of the term 15:57:49 my understanding as well ^