- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Tue, 13 Sep 2022 22:17:50 +0000
Thanks to Our Robot Overlords for scribing this week! The transcript for the call is now available here: https://w3c-ccg.github.io/meetings/2022-09-13/ Full text of the discussion follows for W3C archival purposes. Audio of the meeting is available at the following location: https://w3c-ccg.github.io/meetings/2022-09-13/audio.ogg ---------------------------------------------------------------- Verifiable Traceability Task Force Transcript for 2022-09-13 Agenda: https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Sep&period_year=2022&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date Organizer: Orie Steele, Mike Prorock, Mahmoud Alkhraishi Scribe: Our Robot Overlords Present: Russell Hofvendahl (mesur.io), TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), nis, Orie Steele, Benjamin Collins, Chris Abernethy Our Robot Overlords are scribing. https://github.com/w3c-ccg/traceability-vocab/pulls https://github.com/w3c-ccg/traceability-vocab/pull/552 Orie Steele: I think personally draft PRS are your way of signaling you're not even really ready for a full review and you do expect to eventually be ready and to eventually merge the content if it's not one of those things is probably better to do it on an issue and just discuss because the pr PR is are not a great place to have really unbounded conversations they're supposed to be. Orie Steele: Focus on the changes. Orie Steele: So what do you think the ETA is for getting it out of draft status. Benjamin_Collins: Yeah for me to get the draft the time spent and drops to be like less than a week. <orie> agree... drafts should not sit for more than 1 week Benjamin_Collins: Like all all like my personal feeling about about dresses like all set up a draft and if I'm ready to work on something and then like I'll push commits to it and like I'm looking at the draft and making sure the commit to work and commit to make sense and then like once they make sense like upgrading it to a whole PR like within an hour or within a week like having having addressed here are longer for a week just means that you're not ready for review or not really sure what you're trying to do. https://github.com/w3c-ccg/traceability-vocab/pull/557 Benjamin_Collins: Okay so I guess the three entrees woke up we're going to be for me the first one up is contacts they say I went through each one of those credentials and if we're declaring contacts different in either way and different credentials than I you know there's no reason to be doing that and so this is basically just the way that we expected to be constant they spent the default value speed the car. Benjamin_Collins: And we expect the items to be of type string. Benjamin_Collins: The reflexive Concepts. https://github.com/w3c-ccg/traceability-vocab/pull/558 Benjamin_Collins: Okay so I see the suggestions from Ted and I will committees but to provide some background on what these are is this is the same thing standardization some our credentials included name and description and some of them did not so what this does is this goes through and centers I said to make sure that we have the same couple of fields required across all of our. <orie> in favor of merging after suggestions are applied Benjamin_Collins: I went ahead and committed those so I'll see you guys going to run first. https://github.com/w3c-ccg/traceability-vocab/pull/559 Benjamin_Collins: Yeah I think it should be able to wrote These in a way that shouldn't have any conflict when they merged to try and be safe. Benjamin_Collins: But oh wait maybe to be 0 actually well whatever if we have conflicts and I'll fix them offline and they're just okay so the last one is credential subject it's some of them some of the some of the Json schema we have just had an arbitrary abstract type objects which is you can throw anything in there and I don't think that's what we're trying to do in here so anyways I saw that I prefer provided a spare specific. Benjamin_Collins: Json schema to provide for the credential. Benjamin_Collins: So we can actually render forms from the types. Benjamin_Collins: I can I convert once see I finish it. https://github.com/w3c-ccg/traceability-interop/pulls https://github.com/w3c-ccg/traceability-interop/pull/380 Orie Steele: So the conflict is in the postman collection Json which is like yeah that's that's since it's sort of probably mostly a generated artifact that people are exporting from a postman client I would expect there to be a lot of conflicts for that kind of thing and they were kind of annoying to fix because you have to like import The Collection make changes in export it and over it right to conflict. Orie Steele: There's a good chance that if Chris if the conflict exists because there's already been a merge for that particular collection that there won't be merge conflicts for a series of his poles that are built on top of it so it's possible we might proceed with other items. https://github.com/w3c-ccg/traceability-interop/pull/382 Orie Steele: He needs to alter his code review in order to process this so I would just I read his what he's saying seems to make sense to me and it seems that the action should be to update the schemas not to update embedded schemas in a postman collection. Orie Steele: The change that doesn't include any changes other than to the postman Json file. Orie Steele: So our we're looking at pull 382 the only file you've changed as a postman Json collection not a mo file. https://github.com/w3c-ccg/traceability-interop/pull/390 Benjamin_Collins: Was this what the Saints effectively change from did he did was in the. Benjamin_Collins: Okay it looks like there's a conflict but this is one of the things we were talking about. Benjamin_Collins: I think we can we can discuss this on the call. https://github.com/w3c-ccg/traceability-interop/pull/391 https://github.com/w3c-ccg/traceability-interop/pull/392 Orie Steele: That's okay concrete change requests on pull requests is progress so. https://github.com/w3c-ccg/traceability-interop/pull/396 Orie Steele: Yeah so there's a several confusions here and part of it is my fault there's two endpoints in question there's the credentials issue and point and then there's the credential status update and point both of them are Exposed on the issuer apis both of them take an argument in the post body that refers to the credential status. Orie Steele: And therefore both of those points in our traceability API profile thing have to be aligned with both of those points in the VC API so I am the point that I'm making about breaking changes is if we change any of the argument structure in our test Suite to align with the VC API that is going to break tests like immediately which. Orie Steele: We should make sure that we're really doing that correctly and that the VCA the eye isn't the thing that want to be changing because there's people somebody's going to chase that breaking change on either side you know what I mean. Orie Steele: So I think the the request for this one and this is. https://github.com/w3c-ccg/traceability-interop/pull/396 Orie Steele: Whole 396 the credential status pull request is to review the VC API endpoints to review the traceability API endpoints to discover. Orie Steele: Shape that should be required and all agree to the shape that should be required. https://github.com/w3c-ccg/traceability-interop/pull/399 Benjamin_Collins: I think this is also specifically what we talked about earlier the right where we want to define the relationship between did web and the serbs and point and have a common understanding for that so I don't know if there's a way for me to protect my approval on this one I think we should probably make sure where we have the relationship between did web and how the issue were or how the holder and how the verifier how that relationship is. Benjamin_Collins: Well for me I think we should have let me I think we have a diagram and a couple of examples for if you're if you're issuing an example where the domain for the did web matches up with the domain for the service endpoint and in the cases where also doesn't match up with the service endpoint and you know this and and the basic discover around how that would happen is you know do we need a separate endpoint. Benjamin_Collins: Need a separate Secret. Benjamin_Collins: The Tenon API. Benjamin_Collins: Or can all that you understood from the context of just as it was and how we structure these things. Orie Steele: Yeah I think this is a good opportunity to develop a visual diagram that covers the space that the API intended intends to support So if you're intending to host instances of this API on a unique naked origin here's how that looks if you're intending to host instances of this API multi-tenant using path based routing for the tenants this is how. Orie Steele: Here's how they could be combined if you wanted to start with one and then go to the other I think a clear picture around that would really help with the discovery section of the respect document so I think we should attribute a block a gating factor to this issue to say that we've got a diagram in the respect document that we agree to that covers the cases that were interested in supporting. Benjamin_Collins: Okay I just put something to that effect in there. Chris_Abernethy: I think so can you hear me now. Chris_Abernethy: I apologize for that cause I had a appliance installer coming at a address set. Chris_Abernethy: I think so yeah I did add an additional comments to the issue itself just asking for a little bit more clarification there. https://github.com/w3c-ccg/traceability-interop/issues/377 Chris_Abernethy: So then I guess my question is your to did that Json that I'm representing their above the traceability API service endpoint includes the organization in it so what exactly does that mean should it not exclude that. Chris_Abernethy: Right so that's that's the that's the example I was working with and if you visit that that did not Json URL. Chris_Abernethy: you'll see. Chris_Abernethy: The traceability API service endpoint actually lists you know transmute IT industry / organization / org blah blah blah okay so if that's an endpoint that's going to be used as a URL for say presentations. Orie Steele: Yeah it will be for presentations because that's the use case for this kind of discovery. Chris_Abernethy: So you're going to be serving presentations at one of our L and think identifiers at was a different base URL. Orie Steele: And this is just basically Legacy from the defined Discovery text that's in the respect document today and at some point something got disconnected between what the respect document says and what we're all testing because the respect document actually as far as I'm aware says every traceability and point is available at the service endpoint described by the traceability API which is clearly not correct like for it. Orie Steele: Social issue and. Orie Steele: Financial verify are not exposed at those endpoints. Chris_Abernethy: Got it so I think I think my primary disconnect was not thinking that anybody would be splitting those to live at different points in the the path. Chris_Abernethy: Okay so I see the issue now if you need to support that specific use case then I think I understand what the problem is. <orie> see also https://github.com/w3c-ccg/traceability-interop/blob/main/docs/discovery.md Chris_Abernethy: Really I just was very confused. Orie Steele: Yeah and to be fair I think we are confused as well these things are kind of evolving and when they change they don't always change together and I think that they've changed several times not together at this point. Orie Steele: https://w3c-ccg.github.io/traceability-interop/draft/#api-spec Orie Steele: So we have seen we have two documents that we need to be updating consistently and one of them probably needs to be deleted and then we have interoperability tests that are supposed to be testing the specification so I think. Orie Steele: The right way to tackle this kind of thing is to update the specification first not the tests first make the spec say what we wanted to say and we can review that in English language and then after we've got that we should update the tests and then that's going to result in a lot of breaking stuff and that's okay and then we'll fix it and then the implementations that are passing the tests will be conformed and with the suspect but we should update the spec text on these eight. Orie Steele: Is API Discovery as the next step. Chris_Abernethy: Yeah I definitely plus 12 that and making sure that we explicitly call out that the presentation stuff does not necessarily live at the same place as say identifiers or credentials issue etcetera. Orie Steele: Yeah I think there's like a whole bunch of reasons why it is the way that it is but the main like core requirements are if you have a decentralized in a fire you want to be able to resolve it and present to it like in one kind of clean flow and so that's why you would want those path based routing capability on the endpoint that's in the service for that did. Orie Steele: So API conformance for hosts is not aware of Base URLs that are multi-tenant support and that's kind of more closely aligned to the API did actor example implementation and the current interoperability tests that were all passing and so there's just this one case where you feel this rough Edge and the spa. Orie Steele: Clearly Define that rough Edge and it should work for both like if I want to present to An Origin that should work if I want to present to a path On An Origin that should work the spec text should be very clear about how to do both. Benjamin_Collins: I don't think it's ready for PR what's the specific action. Benjamin_Collins: Okay so the action to be taken as a for the respect. https://github.com/w3c-ccg/traceability-vocab/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc https://github.com/w3c-ccg/traceability-vocab/issues/451 Orie Steele: I've seen it I think we should I just left a comment on the issue but I think we should be surfacing warnings consistently in the spec text so like you know we have that chart that tells us which of our credentials schemas are the best because they have the least undefined terms. Orie Steele: We should have something. Orie Steele: Like that for warnings like this like we should just engineering this so that it's visible it's in our faces were incentivized to fix it and then we should remove the warnings and it's okay if warnings pop up and then they go away and they pop up and then they go away that's all fine I think but it's right now the problem is nobody sees the warnings and so nobody is incentivized to fix them. Orie Steele: Yeah we could do that as well we could make the CI actually error instead of worn but I think that's a bit heavy-handed I think. Benjamin_Collins: Black Market but I think specifically seems to be happening in this case is one of the like one proofs aren't broken like the CIA doesn't seem to be checking the Json schema but when the proof is broken for some reason that seems to like blow over and hit the Json schema Json schema errors which then surface to the CIA so I think the what we want to do here is have Jason seen schema errors always be checked with the sea-ice we're not. Benjamin_Collins: pushing broken schemas do Trace okay. Orie Steele: Yeah that's that's that's right then like what happens if we accidentally publish with over top of warnings like this I think it just means that those credentials actually can't be issue from that schemas that correct. Benjamin_Collins: I think they can because as soon as will still issue because the context is correct but we can't like the schema itself is I mean on these will worthless yeah. Orie Steele: So that's the same thing [...] it's a I think the rule for blocking the CI for the CI preventing merge should be if this is merged will it break an application that pulls from the latest and if that's true the see I should should defend us from that and force the pull request submitter to fix the issue. Benjamin_Collins: Okay alright so I would initially Mike this is right for you. Orie Steele: Yeah the transcription service that we have here is routinely routinely not correct. Orie Steele: Yeah the transcriber is completely unusable in the software and I my preference would be that we take normal IRC notes and Scribe and everyone gets that muscle it's a valuable muscle to have if you're participating in the w3c I think Otto transcriber is a terrible thing and I didn't say what it is saying I'm saying. <orie> Auto transcriber is incorrect... I never said anything like what it is saying. Benjamin_Collins: And like this since the test cover doesn't seem to work for you anyways maybe maybe a sunny ascribed might be become No.1 breakfast. <orie> we should disable Transcriotion. <orie> its broken. <orie> and we need to stop trying to use it. Benjamin_Collins: I would not enable Json schema check in Seattle. Benjamin_Collins: Nothing nothing broken like we have production applications are depending on a usable Json schema so we don't want to be pushing anything broken at any any broken schemas. Benjamin_Collins: Well I think we can do it in a week terrible way possible just like additional properties true and then it sticks and then you know if that doesn't work for your use case and you should come back and make it better. Benjamin_Collins: I mostly want to take the path that gets us to having you know see much action able to see I as fast as possible so all that. Benjamin_Collins: Yeah well I mean II can try and label it we can like see how many errors there are we can try to break it down and if it's insurmountable the or if it's like too much and we can break it up but we should try to get to there as soon as possible. Orie Steele: It's if it's a big wall that needs to be climbed eventually it may only get taller if we don't start climbing it. Orie Steele: That's why we should surface them visually in the report immediately and then you should make modifications to block pull request from being merged if they're going to break stuff as a second action. https://github.com/w3c-ccg/traceability-vocab/issues/297 https://github.com/w3c-ccg/traceability-vocab/issues/300 Benjamin_Collins: Yeah I think a lot of these get into like how do you want the rdf three groups and I think. Benjamin_Collins: you know. Benjamin_Collins: Hannah before we get to this point I you know it seems like we definitely want to have placeholders that schema died Orangeburg general terms and like I think in terms of priority we want to have like very narrowly defined distance schemas for each one of our requirements before we go and really drill down on what terms we want for each one of them is that. Benjamin_Collins: They would never run off that. Orie Steele: Yeah I think. Orie Steele: Gotten rid of all undefined terms will the next thing will be we have defined terms but are they the good the best terms there are we using a schema.org class where we should be using a w3c cube class that gets very much into the world of knowledge workers ontology mapping expertise and out of the world of like a basic tests are passing which we're still failing it so I mean I think these are great tickets to keep it. Orie Steele: Round because they're. Orie Steele: We should be making eventually but I don't know that we're ready for them if we have undefined terms in our Jason Aldean. https://github.com/w3c-ccg/traceability-vocab/issues/304 Benjamin_Collins: I think I remember hearing about this like we wanted to update country code to like a two or three unique identifier and that's something we would have to do with a pull request of schema.org and so. Benjamin_Collins: is that. Benjamin_Collins: Really something that should be addressed by doing it the artist given the word or is that something that can be addressed by just using a different term. Benjamin_Collins: As if there's some kind of wheat if we can use the term like ISO 3166-1 it's like if there's an identifier that does that instead of schema.org country then you know that I think we can just sidestep this issue. Benjamin_Collins: I mean you know what I'm told you that defines you know defines that term and you know. Benjamin_Collins: Because we don't really need to use your schema.org if there's like a un ontology or if there's like a gs1 ontology or something else we could use. Benjamin_Collins: That would solve this I think. https://github.com/w3c-ccg/traceability-vocab/issues/306 Orie Steele: So we've made some improvements on this like we have charts for undefined terms we have the chord diagram for relationships between terms the question is you know what are these visuals that help us evaluate whether or not our schemas are json-ld or already f is is of a higher quality or not so we might want to consider some of the things. Orie Steele: Things that Vladimir was. Orie Steele: You know which ontologies are you based on like how many of the Define terms really come from schema.org versus gs1 versus you know que UD T vs C fabric right so we might want to surface those kinds of visuals and in a way that would indicate or hint you know maybe this thing over here could use more reputable term sources that kind of thing. Russell_Hofvendahl_(mesur.io): I'm sorry but just doing minutes entail. Orie Steele: It means following the instructions in the readme and your long and it takes some practice and effort to do it. Russell_Hofvendahl_(mesur.io): Yeah although I haven't done this before so okay so check out the video I guess. https://github.com/w3c-ccg/traceability-interop/tree/main/docs/weekly-minutes Orie Steele: If it would be possible for someone to pair with him and help him through it I think that would be excellent. Chris_Abernethy: I got it we can do it after this call Russell. Orie Steele: Well thank you Chris. <orie> great work fam!
Received on Tuesday, 13 September 2022 22:17:50 UTC