16:03:04 Agenda: https://www.w3.org/events/meetings/e88d30bd-4099-49d1-b769-1d8cd39a1b28 16:03:04 Scribe: DavidC 16:03:04 Chair: kristina 16:03:04 Meeting: Verifiable Credentials Working Group Special Topic Call on the Specification Directory 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 present+ 16:03:04 scribe+ 16:03:04 present+ 16:03:04 We are going to talk about Directories today. 16:03:04 Response from the chairs on the vc-acdc item will be sent out later 16:03:04 -> https://w3c.github.io/vc-specs-dir/ 16:03:04 -> https://github.com/w3c/vc-specs-dir 16:03:04 Topic: Directories 16:03:04 Manu: What do we want to put in the VC Specs Directory? 16:03:04 … Should be to do with the VC eco-system and existing extension points. 16:03:04 … Then there is a general section for formats. 16:03:04 q+ 16:03:04 … what do we do with a new category as an extension point (not yet in the VCDM)? 16:03:04 … what are the rules for this? Who is allowed write access? 16:03:04 … how much control does the group want over these extension points? 16:03:04 … could be simply a reservation of a term for use later, or could be a pointer to an existing extension point with an example in the directory 16:03:04 scribe+ 16:03:04 DavidC: I'm in the middle of doing a PR for `evidence`, for eKYC, this is work in the OIDF. I thought from the previous meeting, the actual core data model doesn't have spurious examples, but concrete examples, wondering if core spec will have spurious examples, or specific examples? Dummy example or real life example that points to a standard? 16:03:04 Kristina: For evidence, property is defined in core data model, there is already an entry in directory, but could be defined in 16:03:04 directory, would have certain types, those would have document that defines it, like what you're working on, which you would point to from the Directory. Not sure what you mean by "real" vs. "not real" – there is that extensibility point for any specific property to be valid. 16:03:04 Orie: I am opposed to adding `render` to the v2 core context. I am in favor of adding `render` and any other predicates or types, to the vc-specs-dir. The vc-specs-directory has support for “vocabulary” and “contexts” that is all that is needed to support interoperability regarding `render`. 16:03:04 Orie: The working group should work on things that have working group consensus, which means any type or predicates that the working group agrees to take responsibility for the quality of… I don’t believe the working group has the bandwidth or interest to support the render property in the core data model. 16:03:04 Manu: Members should give concrete technical reasons for not including features in the core data model. (Not just their opinions). Options are: put entirely in the directory, or put in VCDM with details in directory, or put whole definition in VCDM. 16:03:04 … need technical reasons for the decision that is made 16:03:04 … one example is the proposed render property. Where should this go. 16:03:04 Adding predicates to a context is writing a blank check… and I don’t believe that is a good practice for the working group. 16:03:04 Kristina: we are not making any concrete decision regarding rendering property itself on this call. You can use it as an example, but please focus on directions around directory - how we decide what should go into a VCDM core. 16:03:04 Manu: One technical criteria is: are different implementors implementing a feature in different ways - this is a reason for providing one standard way. 16:03:04 … another technical criteria is can we minimise effort for implementors by putting minimum features in core DM and then extensions in a separate spec. An example is LD-proofs. 16:03:04 Phil-ASU: there is no process for submission to the directory, so anyone can add anything to it. Whereas for the VCDM there has to be a lot of discussion and agreement before it goes in. 16:03:04 Kristina: Directory provides no normative judgment over its quality nor level of agreement. Whereas VCDM has both. 16:03:04 Dave: Another criteria is different people might try to extend the VCDM in different ways (incompatible) so that both ways cannot be simultaneously added to a VC. 16:03:04 Ivan: if a feature goes into the VCDM then it must go via the Candidate Recommendation route, which provides a lot more verification/review by external people. People "just" defining an extension point may not want to have that. 16:03:04 selfissued: outside the WG can add top level properties to the VCDM via the directory. Is this what we want? 16:03:04 draft proposal: VC spec directory will have an entry for documents that can define a top level property and documents defining those can be defined outside W3C VCWG. 16:03:04 Manu: one extreme for operation of the directory would be to use a process similar to IANA registry. 16:03:04 … concerning the render property we could have two specs: one for the top level property and one for the properties of the render property. 16:03:04 Joe: The directory is not a registry. It is a place to share work being done by people. This is an important distinction. 16:03:04 Manu: We already have the feature that selfissued requested. It is in the section where new types are defined. 16:03:04 draft proposal: VC spec directory will have an entry for documents that can define a top level property (Verifiable Credential Types) and documents defining those can be defined outside W3C VCWG. 16:03:04 +1 16:03:04 Joe: I don’t like this wording. What is a top level property? Where is it defined? 16:03:04 … putting a top level property in the Directory does NOT automatically include it in the VCDM 16:03:04 +1 16:03:04 The group attempts to create a draft proposal: The VC Specs Directory will allow any specification in the directory to define any top-level properties, as long as they do not conflict with top-level properties in the (core?) VCDM. That property does not become part of the (core?) VCDM namespace/ontology/vocabulary.The documents defining that property can be defined outside W3C VCWG. 16:03:04 tallted: What if someone defines a property in the directory that in the future the VCDM want to use the same term for a different concept. 16:03:04 DavidC: What is the difference here? The VCDM is an open world data model - anyone can extend. 16:03:04 JoeA: When people pull in a vocabulary, they don't make what they pull in a part of the VCDM. 16:03:04 Proposal: The VC Specs Directory will allow any specification in the directory to define any top-level properties, as long as they do not conflict with top-level properties in the VCDM. That property does not become part of the VCDM namespace/ontology/vocabulary. The documents defining that property can be defined outside W3C VCWG. 16:03:04 +1 16:03:04 -1 (Joe's arguments about a litmus test were compelling, and the proposal above contains too much that needs to be dissected. I expect a subset of the above to pass). 16:03:04 -1 (conflict vetting is gatekeeping) 16:03:04 -1 (too many nuances to sufficiently capture this quickly) 16:03:04 +1 16:03:04 -1 (need to be clearer about how extensions become core) 16:03:04 +1 (each term has a URL and the official data model is in its own namespace for a url) 16:03:04 +1 16:03:04 -1 16:03:04 -1 proposal text still needs more work to gain common understanding 16:03:04 +1 with more improvements 16:03:04 -1 16:03:04 -1 16:03:04 -1 text could be improved 16:03:04 -1