VCWG Recognized Entities

Manu_Sporny: While we wait for the call to get started in two minutes, if any of any of you wants to do a quick review of uh some of the PRs that have been floating out there for 3 weeks now, uh 122 to 137, I would appreciate it. Um it just needs another review from someone. any of those do. And if I'm gonna unfortunately have to burn 20 minutes at the end of the call probably to just get us to get more reviews on those. Uh which means sitting here and reading through them and waiting until somebody does a thumbs up or finds an issue. So just noting that while we

Recognized Entities Task Force Call

Manu_Sporny: All right, let's go ahead and get started. Um, welcome everyone to the recognized entities uh task force uh call. This is a task force of the verifiable credential working group. Uh, we uh record and transcribe the meeting. Please let us know if you're not okay with that. Um, we do have an agenda today. Um, and we we in fact we have a pretty packed agenda today. We're not going to be able to get through everything, but that's okay. Um, on the agenda today is a review of this registration property and uh how it applies to UNP. Uh there's a PR that was raised based on discussion we

Manu_Sporny: had yesterday. Uh Steve has provided input on that uh which has been great. Uh and that looks like it's headed in a good direction. Um there was also a pull request that Paul you raised uh on um issued 121 and Jason uh that we should review uh today as well. Uh and then there is a metrology uh calibration example that we'll just touch on uh that uh Phil has graciously uh gotten that community to engage uh on as well.

Manu_Sporny: Um, and then I uh unless we get more reviews on the pull requests that have been sitting out there for 3 weeks, we're going to have to burn 15 minutes at the end of the call just to make sure that we get other reviews on these things uh so that we can merge them into the spec. Currently, they only have a review by Dave Long, and we need more uh on them. those uh poll requests 133, 134, 136, and 137. They're all three weeks old. That is our agenda for today. Uh is there anything else uh we should discuss or cover today on the call? All right.

Manu_Sporny: If not, um, a reminder to everyone that W3C TPAC the technical planner is next week. Uh, I look forward to seeing, uh, a number of you there in person and, uh, we'll miss those that are not there in person. Um, but that means our call next week will be cancelled. Uh, and very likely, actually, let's just do this, we will also cancel the call the following week to give people a chance to recover from W3CTPAC. Um uh we do have an hour uh dedicated for recognized entities uh during the verifiable credential working group call next week. Um uh given that we have such a packed schedule today, I will just suggest that I am going to spend the first 15 minutes giving everyone in the room a background on what recognized entities the spec is trying to do.

Manu_Sporny: Uh we'll spend the next 10 to 15 minutes um on where we are uh right now, like where we've gotten to, and then the last 30 minutes uh processing uh any high priority issues uh people uh are concerned about. Um and you know, we can just call it in the room uh you know, which which things people want to um uh talk about. Um, let me pause there. Is everyone okay with that as a plan for W3CTPAC? And I'm very flexible on the agenda.

Phil_Archer: It's all plans a full minute.

Manu_Sporny: I will try really hard to get a slide deck out before I'm on the plane, but I have a feeling I'm going to be working on the slide deck on the plane uh headed to TAC. It seems like that's what I've been using them for for the past 15 years. Um all right. Uh good to know that everyone else headed to TAC is in the same situation. Okay. Uh let's uh go ahead and get into our agenda. Um issue 142. Uh sorry, I thought I was uh sharing. Let me share the window.

Registration Property For UNP Use Case

Manu_Sporny: So last week uh we had uh in fact over the past couple of weeks we've been having productive discussions both on the calls and um in the issue tracker uh on what we can do to ensure that this specification um works for the various communities that uh want to use it. Uh UNP is definitely uh one of those communities. Um uh and uh uh Steve you had raised a number of issues and concerns about you know some rough edges that you felt we had in the specification uh in last week. Um we had proposed like maybe what we can do is we can add a registration property for the UNP uh example. So let me just kind of pull up what this thing you know could look like.

Manu_Sporny: Um so the the first thing that we do is uh registration we add to a recognized entity this registration property and a registration so an entity can specify that hey I'm you know I have a registration that exists elsewhere and the registration uh property uh can be used to express that information. Um, and it can use a variety of different rec registration vocabularies, one of them being UNP, but it could also use digital project product passport or World Customs Organization or, you know, if GS1 wanted to create one of these things, it could use uh that as well. schema.org has kind of a light version of this.

Manu_Sporny: uh and so you've got multiple organizations that have their own kind of registration mechanisms and uh what we're trying to do is enable them uh to um express uh the information they need to um in the UNP use case it could look something like this. So, this registration, um, and I know Steve and I have been kind of going back and forth on, you know, even cleaning this up, uh, a bit more, but the registration

Manu_Sporny: here um basically points to the UNP vocabulary and says do it like they do it over there. Right? So this Acme exports um uh LTD uh is a recognized entity um uh and they have a registration in this uh registration uh registry their registered identity with this registration ID. This is the registration country. This is the ID scheme. The register type is of B is a business register. And this is kind of their scope. Um uh and let me thank you Steve. Jump to the UNP identity anchor thing. And it's it's basically defined here, right?

Manu_Sporny: So uh this is us effectively you know saying like hey you spend a lot of time you know putting this together why don't you use uh this is this is what they they use and we just have to try and prove that like you can issue a recognized entity credential that has a recognized entity that can point to registration in the way that it's done in in UNP. So that that is what this pull request does. It creates a registration vocabulary term and it shows in the UN grid example how you can use that registration uh property. Let me pause there. Uh Steve um what did I miss? Is there anything else that you want to highlight?

Steve Capell: Uh, no. Uh, thanks man. That's good. I I must admit, um, the little snippet that you've got there is one version old. I did take your advice and change ID scheme to register. Uh, and so there is an updated snippet, various updated snippets on on the site. Um, I think this is kind of a nice pragmatic solution. uh I should say quite happy with it. Um one it did actually give me one light bulb moment which is sort of from the poor modeling that you you mentioned. I I kind of realized why I was sometimes struggling with it. Um some of the use cases for registrations the ID of the thing being registered is not the ID of the subject of the recognized entity.

Steve Capell: Uh for example uh a land register recognizes the subject of the recognized entity as the controller or owner of several parcels of land parcels of land and the ID is of the parcels of land or an IP register trademarks or a uh you This separation between the ID of the thing being registered and the ID of the party who has some control relationship with the thing being registered uh has always been a bit of a struggle and this the way we've structured it now uh clears that up.

Steve Capell: So actually I got to thank Manu for that which means really the recognized entity for us is a some kind of authority registar who may operate several registers by the way that's why I use the word registar as the issuer uh so for example the Spanish business register would the legal entity that makes the assertion is register.org or who would say this subject of this recognized entity has these control scopes over this list of registrations. Uh and if it's a land register, it' be a list of land parcels. And if it's a business register, it would be the business uh and so this structure works works pretty well for us in a lot of different use cases, I think. Uh so I would the only feedback I'd have is just correct the snippet.

Steve Capell: uh and perhaps a question for the group like some of the other uh top level entities you know uh there are in other parts of the spec a more detailed uh this these are the sort of properties that might be inside recognized to or recognized in question for the group and the answer may well be no no we're going to leave it just registration and leave it entirely up to the other side what vocabulary you want to put in there. I think that's a reasonable position. Or you might say, well, there are some really common things about every registration. So, we'll add a few optional properties to registration. I leave that up to you guys, right? But I I think yeah, this works. And also, I'll have to admit, helped me with a light bulb moment of what a what a registration really is.

Steve Capell: Thank you.

Manu_Sporny: Excellent. Wonderful. Uh and and thank you Steve for engaging on this the the whole way uh uh through um the uh you know I wanted to respond to your comment around like you know maybe we define some of these properties in recognized entity. Uh, one of one of the really nice things um design outcomes of link data or at least you know the RDFJSLD and the way we're building this stuff is that um we could we could delay that decision later and it doesn't really impact us too greatly, right? like if we start you know if you know let's say uh UNP defines this register thing um and it does it in a way that um all of a sudden starts catching on all all

Manu_Sporny: types of other other places. Um, and we're kind of like, okay, well, this is really the way people are defining these registers and using them. At a future point in time, in a version 1.1 of the specification, we can just pull the UNP terms into the recognized entity spec. uh and and nothing changes other than people don't need to include the the UNP context to use it anymore, right? Um uh and it just becomes a core part in the recognized entities spec and really it would become potentially a core part of the credentials v2.2 vocabulary or whatever we call it uh at that point.

Manu_Sporny: Um so my suggestion is you know let's let UNP run this and refine it and handle that part right this is basically kind of like trying to share the load Steve with your group because you you have the expertise here um and you are engaged with people that have the expertise here to deal with these types of registers like we're not really that group um and then after you're able to kind of, you know, uh, work with that group. And, and of course, you know, we we know like WCO potentially has their own thing that they're doing. I don't know, Phil, if GS1 has anything going on here, uh, and and so on and so forth. There are many different types of, you know, registers and registries out there.

Manu_Sporny: We'll see what the, you know, the the market does over the next um year or two and then maybe we'll have a little more clarity on like one, you know, what are the core fields that that we need. Um so unless you have an objection to that, Steve, I that's the suggestion or the path forward I'd suggest. Uh which means then we just need some other people to take a look at this. I will uh update the snippet. Um, I do want to chat with you in depth about the data model, Steve. Um, I just have a interest in in this particular one. Um, but maybe not spend call time today because we also need to get to uh processing Paul's issue and and some of the other things as well. So, um, let me pause here. Any other thoughts or concerns from anyone else in the group?

Manu_Sporny: Uh Steve, do you have any concerns about that being a path forward that we take?

Steve Capell: your concerns.

Steve Capell: Thank you.

Manu_Sporny: Okay. And a reminder, this is an example and we can update it at any point in the next year and…

Manu_Sporny: a half until we're done with the spec. Right? So, um, this thing that you're looking at right here,…

Phillip Long: Manu or…

Phillip Long: Steve is what's the snippet that needs to be changed about uh scheme? Yeah.

Manu_Sporny: this registered identity, uh, I had a number of questions, uh, both Steve and I have been going back and forth in the poll request. Uh, and I think this

Manu_Sporny: is the latest thing that we got to. Um, and just I'm just going to point things out, Steve. We don't need to, you know, like discuss here, but I'm wondering, so this is a registration. Um, I'm wondering if registered identity is the right name here or it should be like registration. Uh, I was wondering if this should be a register. This used to be scheme ID, but I was like, h, is this really describing a register and the link to it and the name of the register and the type of register? Um, Steve, I didn't understand what control type was until you you just said it um a couple of minutes ago. So, I need to think about like I think it's in the right place, but then I was like, oh, this is like kind of close to a DID controller. Is there any It's not a DID controller, right?

Manu_Sporny: But it is kind of a controller of the registered ID or something like that. Um and then recognition scope I'm you know in my mind I'm like is that a part of like the register does the register have a recognition scope or is the reg reg recognition scope around the ID and…

Manu_Sporny: I don't know you know I don't have a clear idea.

Steve Capell: Yeah. Yeah.

Steve Capell: We we can discuss those things but yeah reg registrations sorry recognition scope is definitely part of the registered ID.

Steve Capell: What it would be used for example is to say this is a registered not for profofit. This is a limited liability partnership. This is a you know it's that and…

Manu_Sporny: Got it.

Steve Capell: that is specific to the the party being registered.

Manu_Sporny: Uh, okay. Okay. All right. So, that that's good.

Steve Capell: Yeah. And I did fix the your comment good comment right about ID scheme.

Manu_Sporny: That means that this is Yep.

Steve Capell: So I think most of your concerns are addressed. We maybe changed the name of the of the registration.

Steve Capell: you borrow classes from an existing vocabulary, right? Which is where that name, the property name is registration, but the class name is uh forgot what it was, registered entity or something. Um, that's where it comes from.

Manu_Sporny: Yeah, it was reg.

Manu_Sporny: Yeah, it's registered identity in DIA.

Steve Capell: Yeah. Yeah.

Manu_Sporny: Um, and I don't know if you got that from somewhere else.

Steve Capell: Yeah. It It's from Yeah. Yeah,

Manu_Sporny: Um, but this feels like reg. It should be registration because it's I don't know if you know identity being a tough word. what does it mean? Um, but these are minor minor things, Steve. Like I I think the general shape I think is enough is is is good, right? Um, okay. So, so my my suggestion, Steve, is like just merge it, you know, with these updates and then we can do the discussion around the internals of this somewhere else. I don't think the PR needs to be held up for that.

Manu_Sporny: So, what we need at this point is we need a couple of other reviews uh to see if uh they're okay with it. Um uh and then Phil, I think you took a look but wanted Steve's input. I think you've heard it at this point. Anyway, we need another review on this before we can merge. I think we're really close and if we do that then I think we have addressed a number of uh issues um in the spec. Let me pause there one last time before we move on to Paul's issue. Any anything else on uh poll 142? Okay, excellent. Um and thank you to everyone uh for engaging on that.

Output Validation Section In Spec

Manu_Sporny: you especially Steve. It's always nice to, you know, address a a thorny problem um in the spec. All right. Uh let me go back to the poll requests and let's pull up Paul's PR next. Uh and thank you very much, uh Paul, for raising this PR. Um, uh, Paul, do you want to take us through the the poll request?

Paul_Dietrich: Yeah, I mean I tried to limit the changes manu to just this feature and not do the GS1 examples. I'll do that in a follow on PR because those are likely to look pretty big. Um and also their examples. Um so what I did here is I basically made a a new section for output validation. I think before it was kind of included into the recognized action but since there were two types um I made this new section um uh output validation and I talked about the ID and then the two types of output validations we have now if you just scroll down a little bit Monu uh JSON schema that's the existing one and then this JSON schema um Dave when I went to go do this JSON can just generate any output you want meaning you

Paul_Dietrich: just generate anything with that. And so I called this JSON out of schema because I said we're going to generate a schema. Um, and so I think that was the simplest thing to do with this and probably lowers the attack surface. Um, I don't know if others need more functionality than that because it can do kind of arbitrary things, but I left it at that. And then Mono, I added this section output validation, which you're about to click on. Um, which talks of Oh, sorry, not that one. Um, I added a section 4.4. Yeah, I uh yeah, 4.4. Um, which talks about the output validation rules. And so we had some of those rules, but we didn't have all of them. Um, and this kind of just enumerates those rules so they're clear in the spec.

Manu_Sporny: Yeah. And this is this is great. Thank you, Paul. And and I did take a look at the full PR and did a review last night and at a high level it it you know it it does what it says which is great. Um, I will point out, uh, Phil, uh, it does not address uh I think your uh uh concern and and not just your concern, right? Like as a working group, we're we have to figure out a way we're going to either use JSON auto uh properly. Uh I will note uh Paul, you know, in your PR, you don't necessarily say how we go from like the Jada schema and the ID to the the end result, right? The the final schema.

Manu_Sporny: Uh there's a bit of a handwave here. We would need to normatively reference something, some algorithm, something that would do that in this step. Um and that I think is the the challenge. Um uh yes, as Ted said, and then a miracle occurs and we have a JSON schema that we can run against the chain. Um, which is, you know, I think we can do like an issue marker and say like, hey, we're still trying to figure out…

Manu_Sporny: how to do this the right way. Um, please over to you, Phil.

Phil_Archer: Um, first of all,…

Phil_Archer: say thank you to Paul for doing this since the person this takes time and and effort and thought. Thank you, Paul. Um, and I also um because I've been looking at this today um and I looked at the status of Jason um and asked my favorite AI what it thought of it. Um and I'm much and I'm the end result of that is I'm more relaxed about the idea of a normative reference to Jason in the document. So um that's with the coach hat on coach off GS1 hat on this uh deliberately or rather this this explicitly doesn't mention the GS1 case. I remain very skeptical that GS1 needs this complexity. Um but I stand to be corrected as always. Um Paul and I are on a call tomorrow. We may well get to this.

Phil_Archer: Um, so I mean it I'm kind of really we need this. Are you sure? I'm not sure we need this, but um as as always I stand to be told that I'm wrong and look forward to the result.

Manu_Sporny: Yeah. And on on that point point specifically, Phil, so that that's great. Thank you for, you know, noting that maybe a Jada normative reference is is potentially in the cards. I am equally uh concerned about it. I I I we need to talk to the Jason authors and tell them like this is what we intend to do and do you have any plans to have a way for us to normatively reference uh your stuff and what are the archival do you have any archival things around it and aren't you interested in doing any you know I think we should have those discussions with them because they are uh IBM employees Phil I'm pretty sure their organization you know wants this stuff to be around

Phil_Archer: Yep.

Manu_Sporny: Um, so we we need to do that. I I suggest we put an issue marker here and say that the group is currently discussing how to properly normatively reference JSON um with the authors of the JSON specification and we will put in the details once we figure them out uh to make it so that we can merge this uh potentially. Um the other uh thing around you know do we need this level of complexity? Um I also have those concerns. So so GS1 does not need this level of complexity if we were going to do the um the the other the field match solution. But I think we're asserting like h we think that people are going to need something beyond field match and that's why we're using JSON.

Manu_Sporny: Um I am concerned that JSON is not going to be enough or if we and again I mean this is this this goes even deeper into the do we need this complexity uh uh argument Phil like I'm I'm starting to I'm continuing to be convinced that I think we need a touring uh the ability to run a touring language on the chain um because of the types of use cases that Steve and the Metrology community and and whatnot are raising.

Manu_Sporny: Um, there just feel like it it feels like if somebody were handed JavaScript or Python that they would be able to do the types of matching they want to do and processing they want to do in a way that they could understand better than having to learn how JSON works uh or working within the limits of JSON in JSON schema. like I feel like we are eventually going to get to the point where we're just going to throw our hands up and say like, you know what, we needed a programming language for day one. Um, you know, that's where GitHub actions got to. They started with the DSL and it very rapidly turned into like a let's just let the person execute arbitrary shell scripts and programs and we'll just sandbox it. Um, you know, that's that's where they got to. All right.

Manu_Sporny: and and I'm totally willing to concede like we're not there yet and I'm not arguing strongly for turning complete complete language but it gets on the spectrum of the things that you were talking about uh Phil. Uh, go ahead Dave.

Dave Longley: I just wanted to say I don't think we all that might might be well and true in due time but if we have a place to put these schemas then we can define what we think we need now and you can add other types in the future and yes that does mean you know people will have some things uh existing in the ecosystem that might take a long time to die off but that's okay that's that's life um I I have not had enough time to dive

Dave Longley: dive into the GS1 use case once more. Um, my understanding is the way that Phil was framing the GS1 use case was to move away from a list of these credentials so that they would they were always extremely targeted to a particular entity uh where the schema would be highly specific to that entity and embedded within the credential to avoid any privacy considerations. and every single one of them would get a different schema that was highly tuned to uh whatever entity you're registering with GS1.

Dave Longley: And in my my if I process that right, I didn't check any of the details of that. But if that if that was the highle thing that Phil was suggesting, that would al be the need for field match or JSON not in that case, but it would not cover the list case and…

Phil_Archer: Paul, do you want to go first?

Dave Longley: the privacy case and the schema maintenance case. uh which might all be secondary concerns, but uh that was my read of what Phil had written and I wanted to say it out loud on the

Paul_Dietrich: Uh yeah, I just had two comments. One, Manu, in this PR, I did put a biblio reference to jsonatada.org, so that'll be a placeholder when we try to go reference that for real. Um, and so it is in the PR. The second comment is I went through a path. um Phil to try to satisfy this model with dynamic schemas and it gets very complicated around the key credentials. That's just our own stuff, but I thought I'd pass that on to you, Phil. And that's where the challenge comes in. If it's just licensing, it works. It does work with dynamic schemas, although the phone home problem is real and the US wasn't really comfortable with millions of members having a phone home. Um so,…

Phil_Archer: Yeah. Fine. Yeah. So,…

Paul_Dietrich: so I think that's where this came from.

Paul_Dietrich: But when you get down to the key credentials is when it gets very difficult.

Phil_Archer: I was all I was going to say on on this is um um think about it. Um and I appreciate that you know work has gone into this and we have this situation now where we have these very real potentially large scale applications like the metrology one and uh the certification one um the certification bodies they're always at least two levels sometimes more than that um so those are important use cases um in our daily work at GSM we talk about certifications all the time and um I keep saying hey we got this thing coming that's going to be really good for for for doing

Phil_Archer: Um the other thing goes through my mind about all this and it it's just the the general antibodies to something that looks complicated. Now what we in this group are very familiar with we have scars on our back from people saying ah link data is a waste of time you don't need this. It's just look just just use Jason forget the LD bit. It just makes it complicated. It adds stuff that no one needs and all the rest of it. In other words, we get criticized already without this for the core technology that underlies a lot of what we're doing being over complicated. I don't agree with them. You I have 20 year history of not agreeing with that.

Phil_Archer: But um nevertheless, I wonder if this is in some ways handing another stick to our opponents to beat us with

Manu_Sporny: Good question.

Steve Capell: Thanks man and Phil. I just wanted to share a kind of a UNP perspective on this. As you can imagine in supply chain traceability and transparency, there are some complex graphs and inevitably the rules that you're trying to apply constraints are across data points from multiple credentials in a in a chain. And you're you're always starting usually in a verification chain from the transaction at the end. So the certificate or the invoice and then following a step and another step and there might be forks in the chain and so on. In other words, the the graph is arbitrarily complex and so we deliberately don't try to put any graph validation rules inside any credential. It's something that applies architecturally on top of the graph.

Steve Capell: And so it it does feel a bit strange to me to try to put a validation rule in a credential which is uh at the end of a chain in the graph that is trying to validate what comes further up the chain that it usually won't know about right won't know what version of a digital product passport ended you up at a digital identity anchor and oh sorry at a recognized entity it just so I kind of support what manner was saying and what Phil was saying that says, "Isn't this sort of stuff outside of the credential anyway?" And whatever we put in the credential is going to run into these kind of complex problems that Manu described. That's just my my instinctive reaction to it. Thank you.

Manu_Sporny: Thanks, Steve. Um, yeah, I I guess the to respond to your point, Phil, you know, is this just another are we giving people another stick to hit us with? Uh, yeah, there I think there there is a there is certainly that, right? And this is a different this is a different uh style of stick. It's not a JSON LD stick. It's a JSON auto stick. So now they've got two sticks to hit us with. Um uh yes, that that is a concern. Um uh but you know, we've got we've got these use cases and we're trying to automate uh the validation of some of this stuff. And in order to do that, uh we have to we have to use some something to do it, right?

Manu_Sporny: Um and it turns out that our use cases are complex enough where uh simple simple tooling is not working right. Um and JSON auto I think is as simple as we can get to something that we feel is generalized enough but maybe in time as Dave said we find out that yeah it wasn't generalized. We're just going to have to keep going down the touring um complete uh uh uh thing. Um uh so you know but but you know to to counterpoint Steve what you said I mean yes it it may be something it may be weird to put this in there uh but we can see the value of putting it in there and that is we can get some level of automatic validation machine uh you know machine run automatic validation that we were not able to get uh before right um uh so the machine readability machine validatability

Manu_Sporny: ility of the data feels like a really compelling um feels like a compelling thing. I I will note that this is following kind of the same trajectory that we had in the render method where we were like, "Oh, surely uh an SVG is good enough to show a picture on the screen." And we very quickly hit the limits of SVG and we were like maybe some kind of you know HTML with like a template in it and it's static and that that's going to solve the problem for us.

Manu_Sporny: And yeah, that solved a number of other use cases until we just got to the point until we, you know, we were like, okay, well then how what templating language do we use? You know, what how how do we do this? And then we just got to the point where we're like, you know what, HTML just does all of this stuff. And if we just sandbox it, then people can use whatever templating language they want, whatever transformations they want, whatever the dour UI elements they want. They can do all of that stuff. and we as a working group don't need to insist that there is one right way you know to do this. Um so that it it feels that like there are parallels here uh to that. Um but you know but what do we do in the in the in the very near future?

Manu_Sporny: Um, I think we have a workable solution with Jason and Paul's raised the PR and I think we put a warning on it and say we're still trying to we're we're still unsure about this. It might change and we can mark it as at risk, you know, when we go into candidate wreck just to let implementers know that we might change this. We might find out as we get implementation experience with this that, you know, we we wanted to solve the problem and we had a way of doing it, but we're going to have to tweak it um during CR.

Manu_Sporny: And I think that's a totally legitimate way to operate uh in the CR, right? Um anyway, uh I'll stop there. Go ahead, uh, Ted.

Ted_Thibodeau_Jr: So, a few things and…

Ted_Thibodeau_Jr: hopefully I'll remember them all. Um, first and foremost, if somebody's got an existing solution that does the job for them, they can stay with that existing solution. We are not taking people at gunpoint and saying migrate to RDF and all these swanky new libraries that we've developed or this new solution that we've developed but rather we are saying there are things that we want to do that existing technology does not enable or permit especially not in an interoperable way. So here's a standard way of doing things at least on the edges that interact with each other.

Ted_Thibodeau_Jr: Again, most of what we produce is blackbox. We specify an input and an output and what you do in between is up to you. Uh so if you can essentially emulate the RDF ecosystem in your SQL world, that's fine. And guess what we do with Virtuoso? We emulate the RDF ecosystem in the SQL world. Um with some exceptions, but that's not important. Next piece of this um somebody looking at the version of whatever if you look at the forms the paper forms used by any reasonably complex paperbased system you will find version numbers and date codes and other obscure information in the borders of those forms.

Ted_Thibodeau_Jr: They are not meant especially to be consumed by the people filling out those forms. But if the organizations in charge of those forms discover that there is a problem with version 12 and they need to dis distribute a version 12.01 they will do so and they will tell all the people who rely on those forms and they're being filled out properly etc. Don't use anything earlier than 12.01 because there was a major bug that we didn't know until we started using it in the field. And you want 12.01 or later. That's reality. And that is the exact same thing that we are achieving with putting version numbers or date codes or whatever else into these libraries or contexts or data files or whatever it happens to be. This versioning matters.

Ted_Thibodeau_Jr: There's a reason why software has versions on it and why they say if you want to interoperate with other people using similar software, you and they need to be on version XYZ of that word processing program. And the document that may get transferred between you may suggest that is a Microsoft thing, but it's really just conformant with the Microsoft format. And the software that I use came from Apple and the software that you use came from Red Hat. And Microsoft will never know the difference even if Microsoft Word is the next thing that opens it up. Those are the big things. I'm sure there was something else, but that's the the major points. If it doesn't matter to somebody, then it doesn't matter. That's fine. That's it.

Manu_Sporny: Yeah, all all good points. Um, yeah, I I mean, you know, going back to uh kind of, you know, the initial thing you said in chat, um, Ted, like, you know, people don't have to use these features. If people don't want to use JSON, they don't have to to to use it. It's a choice. Um and it and it very well people might choose something else.

Manu_Sporny: They might create a new type and um and do something else here and that's totally fine and follows the extensibility model and and so on and so forth. Um uh all right. So and…

Ted_Thibodeau_Jr: Sorry, I I remembered my other piece and…

Manu_Sporny: I'll Okay,…

Ted_Thibodeau_Jr: it's hinging on Jason. Manu Sporny:

Manu_Sporny: go ahead, Ted. and then I'll try to close us out on this

Ted_Thibodeau_Jr: JSON is in this context basically a shortcut for an algorithm and we're describing an input and we needed an output to to happen and JSON delivers the output that we need from the input. It's just a way to do it.

Ted_Thibodeau_Jr: If some other software or some other scripting language or whatever the heck takes the input that we have and delivers the output that we need or want and then you don't need to use JSON and neither do we. We're just using it right now because it's the best thing available for this particular piece of the task. That's it.

Manu_Sporny: Yep. Plus one to that. Um, all right. So, uh, to kind of close us out on this, um, we do need a we need other people to take a look at this and do a review. Um, as Paul mentioned, it just, uh, you know, does a couple of, uh, fairly, uh, focused things in the specification. Um, so I think it's it's good. Um, yeah, take a look. Um, I think, uh, Paul, we will want to have an issue marker here. um just to say like hey we're still trying to figure out how to appropriately normatively reference the JSON algorithms that result in the output here. Um and then there was one other thing here. Yeah, there was this and um yeah, we didn't discuss this. Paul, do you want to speak to this?

Manu_Sporny: There's a there's some there's a bit in here that says like if you have multiple output validation uh uh uh objects uh it's effectively an and…

Manu_Sporny: you have to you have to pass every single one of them not just one of them every single one of them. And I was kind of like I don't know if that's you want to do that. Um, go ahead

Paul_Dietrich: Yeah, man.

Paul_Dietrich: That came out of our earlier review even before the field match stuff where the spec was unclear what happens if you have multiple output validations in an array. And so I was trying to clarify that. I think given that you can have multiple recognized actions, the spec doesn't say what to do if there are multiple ones, but I think it's kind of implied that those are or like you could do any of these actions, but you don't have to do them all. The output validation was less clear. I think in our case, we're looking for the all case, meaning we have two output validations and both need to pass.

Paul_Dietrich: um as long as from your schema you can produce a not condition like this date is not what I want or it's sooner than I want or later than I want then there is logic rule that says this sum of products form where you have ors in the recognized and then ands in the output validation can satisfy complex logic but whether that obscures the meaning of these things is harder to say but so this came from an earlier problem with the spec where it just didn't say what to do with output validation And I was really just putting a stake in the ground here saying this is what we need with output validations.

Manu_Sporny: Yeah. And plus one to that uh for putting a stake in the ground. Um as other people review I haven't had a chance to think about it deeply. Uh Paul um and and I'm just you know stating that uh we'll try to do so. As other people review this uh please think about you know this and and whether or not we want that. I mean, I'm I'm fine deferring Paul to you to, you know, it's like, yeah, we're going to put a stake in the ground and go from here and learn from implementation uh uh learn from the implementation phase in candidate wreck. Uh but I was just pointing this out as something for reviewers to take a look at. Okay, that is uh pull request 144.

Manu_Sporny: Um and I quite unfortunately don't think I topic that. So let me topic this just to make sure that uh it is findable. Um okay so we had a discussion around 144. Uh we also have a metrology use case. Uh, and Phil, I'm just now remembering that uh I mentioned that we would also potentially talk about your transitive uh suggestion. What would you prefer to do? Um, do you know what I'm talking about? There there was a there was a you were like, well, we could do, you know, um, field match or JSON auto we could make this a transitive thing all up and down the chain.

Manu_Sporny: uh thoughts. Okay.

Metrology Calibration Example

Phil_Archer: Um yeah,…

Phil_Archer: I need to um spend time with Paul tomorrow. He and I have got a call with colleagues on this. So we'll we'll come back to that. on the metrology one. Um just a a a stake in the ground. Um the person behind this uh Peter Blatner from the Swiss metrology agency Metas um uh basically they're they're paying for me to go and address their meeting in the middle of November. So I'm really and sorry. So the first thing to say is that he Peter Blackner and Brett Highland who Steve knows very well um who's from the conformity um assessment world uh they're both looking at this and will give us feedback which we obviously need because they are the experts more than anyone else on this call.

Phil_Archer: So, we will get that feedback. Um, and I hope that we'll get that feedback in time to feed that in ideally during TAC, but I'm recognized there's only about an hour or so uh assigned to this task force then. Um, that's because of useless chairing. Um, but but but the point is I want to I'm hoping to be able to go to that meeting, which I believe is kind of a meeting of the world's most accurate measuring stick people um in the middle of November. And if I can if at all possible I want to go to them with something that we with in consultation with them have proposed as a way forward with them. So what that looks like I think all the discussion we're having this evening is very relevant. There are lots of options. I am listening to people. Um I don't have I certainly am not a position where I say no no this must be the only way. I'm not like that. I will listen to what people say. I can see there are various options.

Phil_Archer: Um, I just hope we can find one that suits everyone.

Manu_Sporny: Great. Thank you for that, Phil. Um the so this this uh particular example is very much AI and LLM generated. Um, I took uh all of the writings that they that they uh provided uh all of the input from the issue and I was basically like, "Hey, Claude, can you please create an example based off of the registration uh thing, Steve, um for for UNP?" And I just wanted to see what it would put together.

Manu_Sporny: um what came out seemed like it made sense, but I have no idea metrology or any of this stuff. So again, Phil, very important that they take a look at it because um I read it and it seemed to kind of sort of make sense to me, but I have no idea if it actually works in in practice. Um the you know, the graph it created looks like, you know, most of our other ones. You've got um a recognition anchor up here.

Manu_Sporny: uh recognized entity credential for uh METAS uh which is a national metrology institute um and they issue a calibration certificate and I don't know how that's used but I it's important I take um it it expressed as a recognized entity credential uh I use the UNP vocabulary um Steve uh to do it uses the old version I can update it to use the newer version but things seem seem to slot into places that you'd expect it to slot into. Um, and then this is the the and then the calibration certificate. It doesn't have any highlighting unfortunately. Um, but I guess that like you know this is a specific calibrated item.

Manu_Sporny: It's a coaxial attenuator with a specific serial number and it has a calibration certificate that points back to the calibration framework that was used and the measurement results that came out of it. In using this you can kind of walk the chain up to say like okay so this is the calibration mechanism that they used um uh and uh you know METAS issued this so they're recognized in this and so I go up the chain and it looks like they're uh you know they are an entity that's known uh um uh by BIPM

Manu_Sporny: And uh they have this ID scheme and this they have this scope and the scope you know is here. And so there's this linkage that you can go from the calibration certificate to the organization that did the the measurement uh all the way up to uh the recognized uh uh entity or the rec you know the the the bureau. of um…

Manu_Sporny: what is that? points and measures um that did uh that that is the the the top level entity that's the recognition anchor right so I think it fits for their use case Phil but like I again they're going to have to take a look at it and see if it makes sense

Phil_Archer: Yeah, exactly.

Phil_Archer: I mean it it it it it looks right to my inexpert eye, but we know we need to ask those experts of course, but I just to say they are thrilled that this has happened as you saw in the email from Peter. I mean, he's just over the moon that they're being listened to and taken seriously. So, we've got some very keen supporters there. I I think it's obvious it seems obvious to me that we're not going to get full automation here because those although they are persistent URIs that resolve to um machine readable files JSON or XML with good content negotiation they've done all the good link data stuff that's not going to be part of the out of the box any verification system is going to do that it's going to have to have their own on there so I think this does actually get to the limit of what would I I think it goes beyond the limit of what we can

Phil_Archer: expect automated ver validation to do.

Need For Turing Complete Language

Manu_Sporny: Yeah. Well, yeah. With with an asterisk, Phil, if we had a tour incomplete language, I think we could I think we could do it.

Phil_Archer: Well, I'm sure Jason's not a good evidence. I've learned Yeah.

Manu_Sporny: Well, I mean, Jason certainly can't do this. But this this was the reason I said like I feel like we're headed down. We need it's going to be JavaScript or Python at the end of the day because this use case will not work for JSON auto.

Manu_Sporny: I don't think right um…

Phil_Archer: All right.

Phil_Archer: Okay. Right.

Manu_Sporny: but you know we can we can get at least a good good chunk of it done uh at least express the data can be expressed so that it can be used by uh you know an out of band validation uh algorithm the other thing Phil…

Phil_Archer: Right. It's the same people,…

Manu_Sporny: if you have a chance to chat with them I I don't know what I don't and I don't even know if I'm saying the right thing the conformity assessment credential we have another use case Steve I it's the DPP related I No idea where it fits in, but it was another important use case that I think we should try and uh Okay.

Readiness For Candidate Recommendation

Phil_Archer: man. It's it's it's so it's it's the Steve Capel Brett Highland um um consortium.

Manu_Sporny: Okay. Good.

Phil_Archer: Um yeah.

Manu_Sporny: Excellent. Okay. So, just we want to make sure that we are able to show these um or be convinced that they work.

Manu_Sporny: I don't know if we need all of these in the ecosystem examples, but I will also point out that if we're down to just examples and showing how this works, uh, and we're not needing to change the data model, I think we're in in good shape. And then the examples can change during, um, at any point before we, you know, publish the recommendation. So, I think we're in good shape. Um uh noting that we're uh at the end of the time, um one of the questions I think we'll ask at TAC is do we think we're ready to go into candidate wreck with the spec in the rough shape it is? Are we feature complete?

Manu_Sporny: We do need to still respond to some horizontal review and…

Manu_Sporny: have the horizontal review completed, but after that, do we feel like we're we're done uh from a feature complete standpoint and and we want to start implementing and testing and that sort of thing. I think we're there, but I think it'll be a question to the uh broader group uh if we're there. And finally, a reminder uh that TAC is next week. We will not meet next week and we will not meet the following week. so people can um uh recover from the TAC week.

Phil_Archer: What the hell?

Manu_Sporny: Thank you everyone. Always a pleasure uh working with each of you. Uh and we will see some of you in person at TAC next week. uh and or virtually uh on the telecon. Thanks all. Take care. Bye.

Phil_Archer: Thanks everyone. Bye-bye.

Paul_Dietrich: Thanks. Meeting ended after 00:57:33 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.