Meeting minutes
<ivan> Date: 2023-04-18
PR 1082
w3c/vc-data-model#1082
brent: this pr was raised by manu, everyone seems to be in favor of the general idea
… my hope was to discuss proposals for adjustments to it
<Zakim> manu, you wanted to provide some background on the PR.
manu: some background, we have other PRs that are "stuck"
… they are all trying to add new properties to the Verifiable Credential RDF class in the vc data model
… there has been discussion on too much work, and maybe we should not add more work / other items
… "what work should we take on"
… "what should we delay to a future working group"
… 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
… we might want to address things in the past or future, but the working group doesn't want to say anything normative about them
… the PR is a way to signal that properties are important, but we are not going to say more about them
… seems people are in favor of saying something, we don't know what goes in the table
… so that seems to be holding things up
brent: that is pretty close, but i got other feedback
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
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.
<Zakim> brent, you wanted to add my 2 cents
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
… I wanted to clarify if this PR is just reserving JSON key words, or also IRIs, context. stuff
… my feeling is that properties should be in the table or in the spec... not both.
… I have proposed some changes
ivan: my 2 cents, ories questions should be answered, we should reserve. both json members and URIs, I am neutral on the context.
… implementers should essentially do nothing
… other than not use these terms without the URIs
… implementers should avoid the terms
<dlongley> +1 to ivan
<Zakim> manu, you wanted to ask "how are the vc specs dir categories created"? and to comment on "JSON keywords"
manu: with editor hat on, we have vc-specs-dir with categories
https://
manu: property based extensions, supports credentialStatus, credentialSchema, termsOfUse
… where did these come from
… traditionally they came from the VC Data Model
… editor hat on, I am trying to figure out what compels the editor of the vc specs dir, to create new categories
… the core data model should provide this guidance to the vc specs dir
… editor hat off, I thought it might help to walk people through how we could use the mechanism
… lets look at render / renderHint property
… one way we could address it, multiple organizations want to do something and there is a RWoT paper for it
… lets reserve the term, and say "the wg might do stuff with this term later"
… then the rendering people can work on it in the CCG, as an extension point the VCWG has defined
… we can of course do that anyway
… since JSON-LD is open world model
… wouldn't it be nice if everyone agreed to how to manager extension points?
… render goes in the table reserved properties
… work happens in the CCG, using the vocab defined in the VCWG
… this would let us move other extension points out of the working group, and to the community group
mprorock: I like brent's additions, I would accept the PR with those changes
… I think it is ok to tack stuff in for an editors draft
… if things are well defined, we can remove them from the reserved list
… lets get a base line, and let the community do the rest, non normatively
… lets use do cleanup to the core spec, which needs to be done
DavidC: I think there is a difference between extension points already defined, and new ones that have never been written in the data model
… especially regarding "stay clear of them", they are already defined, and have been used... so we can't provide guidance to stay clear
… since they have been defined since v1, and that is totally different from new properties
… what about other properties, in what category will "isuee" be reserved
dlongley: we need to be careful doing the wrong thing, telling the CCG not to experiment with these
<mprorock> quoting from the suggestion: "Implementers SHOULD NOT use these reserved terms outside of experimental situations."
dlongley: we want people to work on them, to feed those experiments back to the working group
… you should expect use of these to be unstable
<Zakim> 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. :)
Manu: agree with dlongley, there is just one line that you have added that is problematic
… you "SHOULD NOT use these" is problematic
… I agree with mprorocks suggestion
https://
<TallTed> perhaps "use with informed caution" rather than "SHOULD NOT use"
Manu: we should just say: "we are looking for implementer feedback" and "you can use these extension points".
… I would support warning people to be careful, and that they are not stable
… people should be able to rely on the vocabulary term existing, and that its defintion or use might change
… +1 to Mike's table
<Zakim> brent, you wanted to clarify
Manu: I don't like the normative langauge telling people to avoid using them
brent: implementers should not use these reserved terms outside of experimental situations, I am happy to add additional text to elaborate
… it is important to say "Don't use them in production"
… they are "experimental" we can't let people just do whatever they want with "reserved stuff".
… I am not attached to specific language
<TallTed> +1 brent
brent: we all seem to agree in principle, lets get some language
mprorock: we do need clear normative guidance
… you can't assume people will use these things
… they are fine for development, but they should remain cautioned until they are defined
… 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
… people need to be aware of guidance
ivan: as an editor of the formal vocab document... I would like to here answers to ories question from Manu and others
… does introducing a member to the table mean introducing a URL?
… the script will need to be aware of "reserved properties" in ontologies
<dlongley> "if you use these in production, you accept the risk that new versions of the VCDM could be incompatible with your usage"
ivan: will the URL also be reserved?
<Zakim> 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.
Manu: yes, it goes in the vocab... I also prefer to have it in the context
… I wanted to address Brent's comment, I agree with your proposed langauge
… don't ship this to production language is concerning, the working group will end, and then maintence mode, and maybe 4 years from now
… its highly problematic to reserve something for experimentation for 4 years
… for render, we do intend to ship to production before the 4 year timeline
… maybe we can point to vc-specs-dir?
… it does not mean that it might change, the production use could be broken
… 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
… based on the table we see today, I can't imagine us making changes
… the nuance is important
… we should let people use them in production
<Zakim> 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."
brent: can other comment on the suggested changes related to the meaning of the terms?
… would the swap be fine?
<DavidC> should expect -> MAY expect
<mprorock> "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."
<dmitriz> +1 to brent's update
<Zakim> mprorock, you wanted to answer ivan with my preference
mprorock: I wanted to answer Ivan's question
… I have also added a new suggested text, and I added specification requried to it
… I play around with evidence, is different from I have a spec that people are using
… I think clear normative guidance is important
… should they be in vocab? yes. Should they be in the context? I don't have preference
DavidC: I think we should clarify difference between extension points with Type and reserved terms
… for example issuee, is a property
ivan: reacting to what david says, I am wonderign what you mean by type
… type has a specific meaning
… 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"
… which means the maintenance WG can add normative changes
… these extension points could be added here
<Zakim> manu, you wanted to comment on extension points have types... "type": "TheRdfClass" -- also, evergreen was -1'd last time we brought it up :)
manu: I like evergreen, but other don't
… the argument against evergreen, is that the smaller group can modify large normative sections of the spec
… we can try it again, maybe the group has more trust now
… regarding what david teams by type
… I think he means "@type" aliased to "type" and with a value of an RDF class.
<DavidC> correct
<dlongley> +1 to requiring a type for the extension points
manu: it would be normative guidance to add the "type" requirement, and decentralized extensibility is supported by type
<dlongley> (for the values of the extension points)
manu: can we run proposals?
… the working group desires a reserved properties table, the second one could start with the values mprorock has provided
… the third one could be on guidance for implementers regarding reserved status
… encouraging people to use them, but with caution, that they might change in the future
<dlongley> for people reading JSON i think we're suggesting that types are required like this: `"extensionPoint": {"type": "MustDefineThis", ...}` or `"extensionPoint": [{"type": "MustDefineThis", ...}, ...]`
ivan: DavidC has convinced me, that we have to put these entries in the context
… because of @vocab
… 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
<dlongley> +1 to Ivan
+1 to Ivan
<Zakim> brent, you wanted to run proposals
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
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
future, future WGs change definition, putting it in context is saying it won't change, that's the issue.
<mprorock> +1 brent
+1 brent
brent: the reason I suggested the changes I did, I think we can address the context issues in seperate PR
<dlongley> +1 to brent
<DavidC> are these reserved terms or reserved extensions points? they are different
<dlongley> maybe we want to call them unstable or prospective terms? ... since "reserved" isn't quite right per our conversation
<brent> PROPOSAL: the VCWG would like to add a table of reserved properties to the VC Data Model
+1
DavidC: I want a seperate table
<mprorock> +1
<ivan> +1
<dlongley> +1
<cabernet> +1
0
<DavidC> -.001
<dmitriz> +1
<gnatran> +1
<TallTed> +1
DavidC: it seems unclear, I am not sure what it means
<cel> 0
RESOLUTION: the VCWG would like to add a table of reserved properties to the VC Data Model
brent: will you object formally?
manu: I will prepare the seperate proposal
<dlongley> recommends we use "prospective" terms instead of "reserved" to encourage incubation vs. discourage it.
<DavidC> -1
<dlongley> want "confirmationMethod" to say "confidenceMethod" ... or leave it off for now
DavidC: it seems it is trying to do too much at once
… we need to define things, with resolutions, before we can list them
brent: anything else?
<DavidC> then we should call the table "extension points"
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
terms would be a good starting point.
<gnatran> +1 to dlongley's suggestion on confirmation vs. confidence method.
ivan: i disagree with orie, the context is just a mapping
… it is not the "core thing"
… if we agreed, that these terms have a URL in the vocab, the context is the right thing too do
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.
<dlongley> -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.
<DavidC> +1 to Ivan
<mprorock> note, my suggestions says: "Reserved Property" - these are JSON properties
ivan: otherwise people might just use the JSON term
… without the URL
… the context is just a mapping
… I don't understand what you mean, by "extension" point
… we are talking about "Classes" or "Properties"
<Zakim> brent, you wanted to end the meeting
brent: we need to end the meeting
<DavidC> an extension point is a subclass of a json term
brent: this specific PR seems to have general favor
… for parts
… and we should raise issues for extension points vs terms
and vocabulary and context
<ivan> DavidC, I still do not understand. Json term does not have a subclass...
Orie: I'll file issues and leave comments.
<DavidC> conceptually it may have as there can be different types of json terms