K. Cool. Thank you again for, inviting me. I I'm so excited that this group exists. Y'all are the people I've been hoping to find for a long time. So it's great to be a part of this community. I'll I'll talk about my work on a specific domain. And I've given this talk many, many times before. I think some of some of the folks in here might have heard heard it. We are starting to break some new ground that's specifically relevant to this group. So I'm gonna try to give a a from scratch introduction for folks who haven't heard about this stuff before, but hurry along to the point where we could maybe have a conversation about the sort of frontiers of of this work. And I've shared in the Slack links to a paper that just came out in the Cambridge Handbook of Commons Research Innovations that gives an overview of this work from the lens of common pool resource management and the Ostrom School along with two less technical resources, a white paper, and and some infographics that we've been working on. You don't have those links, let me know in the chat, and I'll try to get them in here. Otherwise, look in the Slack. And I will walk through, if it's alright, basically, just a presentation that covers the same ground, but, hopefully, this is helpful for you all. Right on. So I'm gonna share my screen. Does this work? Okay. So, again, my name is Greg Bloom. You can find me at the at the, you know, channels listed here, and I I include a link to the paper and these diagrams as well in this front front page, and I'll I'll share a link to the deck. I lead the open referral initiative, which is an unincorporated community practice. We have fiscal sponsorship through Aspiration, which is a five zero one c three in, in San Francisco that provides capacity building for, nonprofit social good technology projects. But, yeah, generally, open referral is an open network, a community of practice that I've founded and facilitate, dealing specifically with the challenge of resource directory information. And this network emerged after years of work that I did in the field at an organization that provides many different kinds of health, human, and social services to people in need, bread for the city and the District Of Columbia. They have a food bank. They have a food pantry, medical clinic, legal clinic, social services. And on top of everything else that they do, they maintain a database of all the services to which they refer people on a regular basis. And what I discovered when working at Bread for the City was many people just came to us knowing that we would be able to tell them where else to go. The fact that our, our service providers, our social workers maintained a database of other services actually increased their workload. They didn't have to do it, but it was important for the, you know, for the quality of their work and helping people. And I I couldn't believe that we were maintaining this database on top of everything else. And then I I I observed over the course of five years half a dozen projects at least that attempted to take that database and turn it into some sort of centralized community resource clearing house or or, you know, or or build, like, the new one stop shop for all information about all the services available to people in need. And that's how I realized that this was actually a very wicked problem, watching a series of failures over a course of about five or six years. And the problem simply described is that it's actually very difficult to see the safety net. It's very difficult to know what resources are available to people in need. People knew in DC that Bread for the City helps people. That's more or less all they knew. They'd go there to figure out where else to go. And so this is the specific realm of data that I'm referring to here when I'm talking about, quote, unquote, seeing the safety net. The term of art is community resource directory data, which refers to information about organizations that provide services in places, virtual or physical, and and details about how those services are accessed. So this is a realm of information that is actually a lot slippier, than people a lot more slippy than people expect. The data is very complex. Organizations might provide many different services at many different locations. They each of those services might have different criteria, elaborate criteria as to who's eligible. You might describe these services in different ways to different people depending on the context. Right? The words that people would use to describe services will differ If you're a funder or if you're a manager or if you're a person seeking help or the person at the front desk, you use different words to describe the same things. There's not one government agency that can just, like, open the data. Right? These are services that are provided by a fragmented array of institutions across sectors. The the hardest part of this problem isn't even on this slide. The root of this problem on top of all of this complexity and slipperiness is that organizations that provide services to people who don't pay them for those services don't have strong incentives to be found by more people. Right? They are not paid by their funders per person they serve normally. And even in some instances where an organization that helps someone in need is paid by their funder per person they help, they're usually not paid enough to cover the costs of that service. So it's not an incentive for them to promote their own information. What ends up happening is that there's a there are fields of intermediary organizations that collect that information. And if you want good information, you have to make phone calls. So what ends up happening is there's all of these nonprofit organizations and now increasingly for profit organizations that make all these phone calls a to b through a list of organizations, ask them every year or multiple times a year, what are the services you provide? Blah blah blah blah blah. They try to send out emails. I was the person that would get the email from my organization. And after filling it out twice, you know, in two different or in two different directories, I was like, you know, this is a lot of work, and I'm not actually expected to do it, so I'm gonna stop doing it. So the more and more of these directory providers there are, the less and less likely any organization is going to respond to any of them, hence our collective action problem. This is what that looks like. Very simplified diagram that shows you have many different organizations, providing many different methods of referral to various types of users, and they're all chasing more or less the same information. And with each new directory, the problem actually gets worse. And many organizations have oh, let me this is a blurry, example of what the data actually looks like. I'm sorry it's so blurry. But this is from one of our pilot projects, the same organization represented in three different directories with three different names. And the information about that organization across each directory varies a little bit. Only one of them has the most important information, which is that, the the actual intake hours where you could not just get into the building, but receive the service are only eight to 5PM, you know, Monday through Thursday. Right? Like, it's 20 04/07, but only one of these directories has the specific information someone would specifically need to access that service, which is just because someone there knew what questions to ask. Right? And so we see in this proliferation of information more and more data, quote, unquote, but supply the the supply does not actually meet the demand. And when I was describing this problem ten years ago, five years ago to very savvy Internet people, entrepreneurs, hackers, etcetera, the response I almost always got was, why don't you just scrape everybody else's data, pool it into one site that's the best, and everyone will use your site, and you'll win. And we need you know, I strongly believe we need to apply different logic to escape this cycle than the logic that got us into it. And we've seen many attempts to sort of build, like, the winner, the website that everybody would use, and it really only ends up making this market more crowded and toxic. And so my question coming into this after learning about how difficult it was is can we take a different approach, a more ecosystemic approach in which this public information is not a commodity? It's treated as infrastructure and managed as a commons. And so the vision for open referral is that this information about the resources available to people in need should be accessible, you know, in any number of channels. Right? Like, the water utility or power, you should be able to get it in a toaster, get it in a microwave, or or, you know, or or get it in a TV. And and and that means we have to disentangle the challenges of collecting and managing this information from the challenges of delivering it, right, of actually getting it to people. Those challenges are currently in the market all bundled up together, you know, end to end. And open referral is saying, can we establish infrastructure that is essentially pre competitive, right, in which there's some means of collecting and managing this information as a commons and and maintaining maintaining the accuracy of that information. But then that that information is available through many different channels, some of which might be competing with each other. To give you a sense of the scale of the labor of that maintenance, for an average metropolitan area, you're probably talking about two full time employees to maintain information about, 1,500 or so different services. Right? Like, it's a lot of work. The two full time employees is probably about like, in any given community, you have more than two FTE being allocated just in disaggregated silos, competitive silos. And so what we're asking through open referral is, can we align the resources that are being thrown at this problem through cooperative infrastructure in some way? And the first step that we took in that direction is not what I would normally recommend to people, but we had the opportunity to do it. And so we took that opportunity as a way in. The first step that we took in this direction was to develop, data exchange standards. At first, I didn't call them standards because there's a lot of baggage around the term standards. We just call them specifications. But we developed protocols that any organization that maintains a directory in their own database could use to translate its schema of organization services and locations or agencies, programs, and sites, whatever what have you, translate it into a common interlingua and exchange that data with any other organization to reduce the technical friction of exchanging data that oftentimes sinks cooperative partnerships before they really get started. And we developed this standard specifically to align with existing and emerging standards. Right? So we we specifically developed an exchange format that could map to the legacy standard for call centers and could map to the emerging standard for website markup that Google put through schema.org. Right? That was our opportunity was to say, there are these existing standards. We are going to develop the means to cooperate among them, which if people are interested in standards, politics, you know, that is a key way to escape the logic of that one x KCD cartoon that everybody brings up when they are trying to shut down conversations about standards. So we developed a cooperative interface among these different technology ecosystems. And then eventually in 2018, the alliance of information and referral systems, which accredits information and referral providers, the the sort of conventional realm of hotlines, and there's, like, 1,200 of them throughout North America, all in this one industry association as members. And that industry association recognized that these specifications are now standards. So that was, like, our first objective was to establish standards for interoperability. And that was a necessary breakthrough. It was a a big deal that meant I hadn't wasted, you know, four or five years of of my life. But it really only, created a floor on which we can now try to build the real solutions, because, ultimately, the standards now that we've got everybody to agree, okay. There will be standards. There are standards. We'll use these standards. They don't answer the question of who should be responsible for maintaining this information. They just expand the range of possible answers to that question and enable us to make those answers work together. Right? And so this is ultimately the big question that we have to tackle is given that this resource information ought to be accessible through all these different channels, it's public information. It ought to be used as a commons, but it requires resources, energy, phone calls to maintain. How can that maintenance be sustainable? That's that's ultimately the question we are trying to answer now that we've addressed the technical friction of exchanging data. We have we have the basis on which to address this institutional design question. So, I'm wait. Let me see. Before I get into, our models for potentially solving this problem through an institutional basis, I see at least one question from from Seth. I can pause here and see if there are other questions that people have about what I've laid out so far. So, Seth, you ask, what's the rationale behind leaving referral providers between open referral and people in need? Why not correct connect directly, especially if people in need are the most incentivized to maintain data quality? So you're referring to this diagram back.

Yeah. This one.

So and and I should clarify this this diagram, which I am working to improve, it is a little misleading in that open referral does not build a platform.

We're not gonna build software. This is the vision that our standards make possible of infrastructure. And I do need to

Yeah. I mean, to

Yeah. So there's a couple things here. First and I think there's a couple things in your question that I'll try to tease out here. First, the reality is if if you need help, you you first of all, like, one place is not going to be able to help you. You might not even know what help, like, what to ask for. And and so the reality is the day to day use case for this information, even though the ultimate beneficiary is people in need, the day to day use user is probably a service provider of some sort who's probably in a position to offer someone some help and then maybe refer them back out somewhere else. Right? And so the basically, what we're saying is those intermediaries, the the name of the game is not disintermediating. Right? It's it's about ensuring that the same reliable information is available to all the different intermediaries. Right? And open referral just offers the technical protocols to make that supply chain happen.

Yeah. And and and, also, one more thing in your so we'll talk I'll talk about the institutional designs for, like, who should be the supply chain, next. But I also wanna address in your question, you asked, you know, if people in need are the most incentivized to maintain data quality, I I maybe that's implying, like like, couldn't the crowd, couldn't the users be the ones to produce this information? And that's where I started. Right? That's where I started on this work eight years ago. I was like, all these call centers are old school. Right? Like, they don't know the power of the Internet. Let's just build a Wiki. Right? And people will maintain the information themselves. It it didn't work. Hasn't worked. I don't think it will work. And I can talk I think it's interesting to think through why crowdsourcing as a promise, you know, was never realized and probably won't be realized in and of itself, which is not to say that we don't want user feedback, and we don't want systems that solicit input from the people who use the services or the people who provide the services. It's just that those are potentially inputs, and they're not solutions in and of themselves. The crowd is not does does not turn out to be magic as it as it happens in at least in this case. So I see a question from someone who doesn't seem to have a name on my screen. Who's who's hand's up? Hi.

That that's me. I'm Z. Oh,

yeah. Hi, Z. Okay.

I was gonna ask a a sort of clarifying question kind of as you're talking through it, Seth. So it seems like what you're really providing is the the communication protocol or the standardization of the data structures potentially of APIs. And I think to the question or or to the discussion of, you know, the data quality, I think, it sort of underappreciated how much, standard data structures affect data quality. It is a lot easier to maintain data quality. So maybe just lowering the friction and making it clear what high quality data is can result in higher quality data without necessarily solving for who is actually going to do that because it's just less hard.

Yeah. There's, yeah, there's something to to be said for that, although it also results in more work. Right? That's why a lot of people are resistant to standards. You know, the technologists will often throw up all kinds of reasons why standards won't work. Oh, like, standards are great. There's so many of them. Right? And so on and so forth. But, like, ultimately, what we're saying is, like, we need some baseline agreements on what to expect out of this information, both at the level of content, which is a little bit less what we focus on. We primarily focus on just, like, assuming you have these information elements, here's how to structure them to just move them from one system to the next. Although implicit in that is if you get a partnership together where you have multiple organizations that want to share data in some way, that is probably going to involve politically quality improvement of that information, not just, like, use the standard and solve the problem. Right?

Yeah. I I'm with you on the the standards issues thing. I think I've just back to this diagram, kind of I'm trying to modify it in my brain, and it's almost like it's the it's if the left and right brown boxes are talking to each other, then, in fact, what you're drawing is the description of the green arrows. You're talking about the attributes

That's right.

Of the thing That's right. That the green arrows and then you have a many to many graph between the left and the right, but it's actually possible to have a many to many graph to the left and the right precisely because you've created this thing with verification interoperability, open data, automatic updates, etcetera, that provides the means of of reliable communication. And to the point about the standards adoption, though, I mean, people use the term standards frequently and and understandardized that their their candidate standards or potential standards. There's a big difference between achieving standardization and attempting to achieve standardization. So if you have found a way to get people to start using the same data structures and APIs, you're going to start off a new process that can emerge on top of that.

Yeah. And when I started this work, people told me it was not, like, it was quixotic and not possible to get like, to establish a standard. Right? There were some existing attempts that were never really fully baked, and and technologists were just like, yeah. Like, standards would be great, but there's a collective action problem, and it's not solvable. And the difference was, like, I'm I'm a community organizer, and I like talking to people. And that was literally the difference. Right? And it's it it turns out if you talk to people and you continue that process and you build relationships, you can broker piece by piece the cooperative value proposition that that overcomes the collective action problem of, like, too many standards. Right? That you you you figure out, like, if this group can cooperate with that group, let's make that happen, which is gonna incentivize the next group to cooperate. And eventually, you reach critical mass, and the industry association says, here it is. This is a standard that, you know, they've done it. And that's basically the path that we took. Again, it just brings us to the point where we can now answer this question. Right? Community by community, we can now answer this question of, you know, now that there's a common language for all the machines to talk, who should be responsible for ensuring that the information is up to date? And so this is gonna loop back to that question of crowdsourcing. This is a a somewhat cheap diagram that's, like, somewhat referencing that sort of classic diagram of the public goods and club goods and, you know, and so and so on. I think I could improve this. I would welcome your feedback on improving it. But let me walk through this really quickly and then talk through each of these models that we're exploring. And there's one in particular that I wanna talk about with this group, which is in the lower left hand corner. But let me start with crowdsourcing, because there were many wikis ten years ago that I that I found, and none of them survived. And I saw a question about, like, if there was the standard, would the you know, you know, if we'd had the standard, could the wiki have survived? And I don't know that that's that that's the case either. And I should clarify. Like, I do believe in the potential value of the crowd of user feedback. But this inform like, as far as I can see, successful Wikis have a match between, like, the kind of knowledge that they're trying to manage and the the kind of audience that that that they want to attract. Right? So Wikipedia is, like, all the world's knowledge, and they managed to get, like, all the world as a user base. Right? And they're that's a match. Right? But it's, like, it's the notable information. So anybody anybody using inform Wikipedia should be able to access, theoretically, like, any of the notable information that could go on to Wikipedia. Likewise, fandom wikis are also really successful. Right? You have the Harry Potter canon, and you have a lot of Harry Potter fans, and they're they all have access to all the facts in the Harry Potter can canon, potentially. Here, we have a situation where it's like, there's a food pantry offered in this building on the corner of my block, and the building's operated by this one organization. But the food pantry, that actually might be operated by this other organization. Am I, a user of that food pantry, expected to know the details of the organizational structure of the of this program? Like, those details matter when it comes to effective databasing. Right? But they are not something that the users will actually have in their minds. Right? Not reliably. And and and so, like and the the number of people who have that information or who want to aggregate that information is more like in the dozens rather than in the hundreds of thousands or millions. And so what I found was when I took a database and put it on a Wiki, the people who I wanted to get to maintain that information wouldn't trust it. Right? And so we weren't able to reach critical mass because they found, like because, like, they're just, like there wasn't an answer to the question of how well we know. We didn't get to that point of self correction feedback loops that that you get with a large Wiki at a certain scale. And and and so, again, like, I don't wanna shut the door on it entirely, but what I found was that it was a a potential input in need for an institutional intermediary solution. And so these other these other models is what I eventually ended up exploring, some of which I got from the literature of common pool resource management, you know, governance, and and some of which I gleaned from, like, other kinds of data economies. So none of this is new. This is patching together what we observe in our field and in the literature. So I'll walk through it. In the top left, we well, we have the intermediated, meaning, like, some or, like, a third party is responsible for producing this information or direct, meaning, like, the provider or the user is producing the information, right, potentially. And then we have canonical, meaning this is official information or coproduced. Right? I'm borrowing that term from Ostrom. Meaning, like, these are essentially, like, ad hoc relations among among, you know, among peers. And so in the level of intermediated and canonical is what I call a data utility. And I think it and I'll talk about it in a little bit, but it's one organization that maintains the official list. So it's one intermediary maintaining the single source of truth of information for a community. That's one model. Another model in the canonical mode is a service register where it's an official list of all the services within a given domain, presumably established by an authority to which service providers are accountable. And the authority can say you have to be listed in the register, and the service providers update their own information. And then in the bottom left, there's the intermediated co coproduced model of a federation or a collaborative if you're being a little less fancy. Right? I find Americans are really intimidated by the word federation. The word collaborative isn't as ambitious as I wanna be. But, you know, I I so I use them somewhat interchangeably. But this is multiple organizations maintaining overlapping resource directories that cooperate in the management thereof. And that's what I really wanna talk with y'all about assuming we have a little bit more time. I'm gonna talk through every one of these models. So if you have questions about the models, let me know. But any questions clarifying before I jump further in? Okay. And this is outlined in the final section of the paper, and these are also like, these diagrams are also outlined. Like, I shared these in the infographics. I am trying to improve these infographics. This is my best attempt to convey the sort of, like, supply chain cycle. But so I'll start here with the registry model. And for this, I'm borrowing from the Open Data Institute and the UK General Digital Services definition of a register, where they say, you know, a register is an official list. An open data register is, like, data that can be queried by third party systems. And they specify in in their literature that, like, the most important thing about a register is if you want it to be considered canonical, someone needs to be responsible for ensuring that it's accurate. Right? There needs to be a custodian. So it's still like, it's not a automatable thing. But presume presumably, you have some sort of authority institution. In this instance, we've we said a funder, but you could also have an accrediting agency or a food bank could have a register of all the pantries that receive food from it. Right? But there's some authority institution that says there will be an official list. Every provider within their remit is expected to update their information. And what we have here is a data custodian that ensures compliance with that requirement, and then the information is available to all the third party systems. Again, because this still requires intermediation, it's not a silver bullet because it's, like, really contingent upon some sort of authority. It's not really scalable as a solution, but it is a valid model we've tested in the field. It is as long as we're using standards, it's able to be, like, a modular tactic alongside a broad broader strategy. Any questions about the register model? This is one I often use to talk to governments, saying to government agencies, you fund services and you provide services. How about just focusing on ensuring that accurate information about those services is available in a register on your open data portal, for example? So, the utility model is, most commonly what I get paid to help organizations try to figure out how to become. Right? Where you have one organization that's positioned because it has the trust of the community and the capacity to do it. They're positioned to be the single source of truth, quote, unquote. And they maintain all this information specifically by having a staff that they train and employ to to maintain the information, where that staff then collects the information from service providers as a third party intermediary, and it provides it as open data. The question here is how is this sustainable? Right? If you have two full time employees that are maintaining information that then you're making available as open data, how do you recoup the costs of their of of their labor? And here, I I think the best answer is probably some freemium model that looks like essentially club goods. Right, where the data is a public good and the services associated with the data that organizations might wanna pay for are essentially club goods. Right? So the you'd anybody can connect and, you know, hit the API and query the data, but maybe you want high volume access that is guaranteed to be ubiquitous for the duration of a contract. You pay for that. Right? The free version comes with no guarantees. You wanna guarantee that it'll be updated. And if you if you find information is incorrect, somebody's gonna respond to you in twenty four hours. That's what you pay for. Maybe you could build your own website, but, you know, the utility can offer you a white labeled version and slap your logo on it. That's what you pay for. Right? So this a lot of my time is help is spent helping communities with organizations that traditionally offer operated just a hotline or maybe a hotline and a website, but, like, they could become a new kind of data service provider to organizations that are otherwise competing with them. And we facilitate the process of essentially new kinds of business development. And there's a lot of questions about governance here, but this is still something of a simple story compared to where we really wanna go, which is what you could call a federation. Oh, and by the way, on each one of these diagrams, I didn't wanna let this go without calling it out. We we conveyed this in haiku in the top left. We wanted to show, like, a narrative, a text narrative, a visual narrative, and also a haiku. So there's multiple ways of of conveying, you know, what this model is. So here, the haiku is a federation, shared responsibility, mutual benefit in which you have multiple organizations maintaining overlapping sets of information, and they can divide responsibility and share the benefit across this network. And this is what we're only just now starting to dig into in terms of, like, the complexity of arrangements and rules and processes that would have to be in place to enable this to work. And that's what I wanna talk with you all about. Yeah. I'll pause here. Real quickly, you know, the the very last slide is basically saying, the way we do our work is through pilot projects. You know, this is not just we sit in a ivory tower and postulate about what would work. Like, each one of these models, we are trying to test in communities. And I should also point out, these are not either or models. These are, like like, these are plug and play modular approaches. These are these are really tactics that ought to be employed in some way, probably, like, in some hybrid strategy. Right? That for example, like, a funder is not likely to want to be responsible for custodianship. Right? Like, they're not likely to have the technical capacity or staff capacity to deploy and maintain and monitor or register. They could pay a utility to provide that service of a of a service register. Right? And, likewise, a a federation, I think, is most likely to succeed if you have a single organization that's responsible for bottom lining that collaboration. Right? Is that the only way to make it succeed? No. But these are probably arrangements that ought to be deployed in some combination with each other. And this that precise combination is going to be dependent on the local institutional landscape, which is highly variable. You see the same patterns, but in different configurations each place. And and to to Edward's question, we're working in you know? I mean, I'm personally working in about half a dozen or so states or major metro areas as a consultant, helping communities figure this out. Right? Like, my my role is usually, like, facilitative. Sometimes I'll bring together a team. But, of course, I don't even need to be involved. It's an open network. Anybody can try to make this stuff work. And we also have promising projects in in Canada and The UK, and we're talking with the primary provider in Australia. I've only had a few instances where we've gotten some traction outside of the English speaking world, and and those didn't really, like, catch on. But but I I also think in a lot of places outside The US I don't wanna say this problem doesn't exist, but The US is somewhat unique in its approach to service delivery. A lot of places, it's just like the government manages this. And and and I'm not saying it's not a problem, but it's a less of a hairy problem. Let's see here. Yeah. And and, Edward, we have had various projects in crisis response. It's a tricky one to sort of, like, plan for because it's hard to, like, run tests on crisis response activities in times when there's not a crisis. And I see a question from Seth since open referral has been out for a bit. Have you had a chance to see any of your own hidden US or Western non other context assumptions bubble up and and get fixed as adoption increases? So okay. Let me see if I can frame that. Like, Seth, one example of an assumption that I'm uncomfortable with that got baked into this initiative, and I I've had to just sit with that on discomfort, and I think outside of The US context, it might be more important to address, is that I don't like, we call this community resources. We call this the world of community resources, but our data model assumes that a community resource is provided by an incorporated organization. Right? And it assumes that if you wanna, like, you know, address the needs of people in need, like, the way to do that is to connect them with some sort of provide or service provided by an institution. I actually don't think that that's, like, like, a a very, like, effective if we're thinking holistically, that's not that's not, like, a a great way to think about the world or about resources. Right? Like, there's all kinds of resources that are just provided in ad hoc mutual aid networks and so on and so forth that it should be, you know, potentially a, you know, an awkward fit in our data model. And, you know, I do have some concerns that if we, like, sort of, like, double down on the idea that, like, organizations provide services, period, you know, there there may be some some ways in which important collaborative potential gets obscured. But I I actually don't know how I I I hold that concern lightly because I think, ultimately, like, this is a source of information about a kind of resource, right, or a domain of resources. It doesn't it doesn't preclude that information being used alongside information about more ad hoc mutual aid resources. Right? Like, the you know, it's not exclusive. So But but but it

Yeah. That's why, you know, community resources is is a nice simple shorthand. Usually, I specify health, human, and social services. Right? And, Z, I see your hand up again.

Yeah. So I I I'd just like to jump in this conversation because, I mean, one, this is a area that I'm also really interested in the the data represent the knowledge representation is and its effect on the systems that rely on it. So, you know, maybe the question I would have is, like, are there meaningful ways to adapt the ontology that you're using to be a little bit more expressive of these things? Like, is there a way to get a a class of organization into the schema that's representative of a more informal organization and then to capture information about the norms or the access points? Because you're not gonna be able to provide all of the details about every individual within a mutual aid network. But if there is an informal institution that is representable, then Yeah. I think within reason, you could capture some norms about how to, like, kinda get access to someone within that network to get more information.

Yeah. And I think that's right. Like, I don't know that it's the it's gonna be, like, the most appropriate or effective way of, like, tracking mutual aid groups, right, to try to use our data model to express information about them. But it's possible. Right? It's doable. Right? If you if you're able to describe some sort of group, right, it it can fit into our data model. A group provides services, right, at places.

I'm trying to touch on something slightly different, which is that it doesn't need to give you all the answers. It needs to make sure those things aren't invisible. So, like, if they're not represented at all, it's as if they don't exist if this thing is popular and it's the main source of information. If you can represent its existence and provide even a minimum viable pointer to how to get more information about it, then you at least have an erase to that modality.

Yeah. And one last thing I'll say about the spec, and then I do wanna get into the governance challenges that we're finding with this federation challenge. The spec is designed to be extensible and compressible. Right? It's it's really, like it's not saying here's the truth. It's not saying here's how you structure your database. It's saying these are common terms. Right? In The UK, they're developing a localized version that specifies, like, aspects of UK addresses or things like that that we don't have in our main spec, and that's great. Right? And we have to we need to have, like, better ways of technically supporting that kind of localization while preserving interoperability. That's an interesting aspect of data standards that I'm, like, learning about that I think could be improved for many standards. But, like, that's the idea is that is that this is meant to be a common reference point that different communities can adapt as they see fit. As long as they're documenting that adaptation, they can still be sort of, like, a interoperable part of this broader ecosystem. So I can get into what we found when we have tried to establish these federations because I think that's where it gets to really that's where it gets to, like, the questions of governance that I think we have yet to answer. I'll talk about a project called ServiceNet, and I can share links to more information about ServiceNet. A partner of mine called Benetech in the Bay Area built they they build, like, in like, technology infrastructure, data infrastructure. So the not not websites for end users. Right? They built, like, the tools for intermediaries. And what they built was a system where if if I have a directory and z has a directory and Divya has a directory and they overlap, we can load our directories into ServiceNet. It will transform it into this standard output if it's not already in it. It will compare the directories to each other. It will identify matching records, and it will show us the differences between those records. Right? And then we can edit. Right? And the I think it was, like, once we've done that, that's a necessary first step to then being able to have these organizations collaborate, right, on managing information. So if I make an update to a record that's in your system, you can get that update. With me so far? So so, like, here's here's what went well. Like, they they showed that, like, first of all, the standard helps. Right? It becomes a lot easier to find those collaborations by having a standard. Right? It it involves a lot less time if your data's in a standardized format to compare that data to other records. They got to a point where they had a reasonably high match rating between systems, and they specifically learned this was a really interesting detail here in the weeds. Organization name is actually really hard to match. It's like we saw earlier. Like, it's you you have different ways of writing an organization's name. Right? Is this United Way or United Way of San Fernando Valley? Right? Like like, different directories may have it in different ways, and it's hard to mechanically match it. But you can mechanically match addresses. And once you've mechanically matched addresses, you can then mechanically match organization names to a reasonable degree. Right? But what they then found was, like, the services, even with a standard, information about services is just plain subjective. It's not factual. Right? If I had I might describe this food pantry as a food pantry, but you might describe it as a food assistance program. Right? And those are not like, at scale, it's not really possible. Like, even worse, like, I might describe the service as a health clinic. And you might say, this health clinic is a program, and each one of these different things that it does is a different record in my system. Right? The so my system says health clinic, your system you know, in in the in the description of the health clinic, maybe I have a bunch of bullets that say things like, you know, primary care, needle exchange, dietary counseling. Each one of those bullets is a different record in your system maybe, and they're not necessarily mechanically resolvable. Right? And and so what they found was given that reality, even though they could match organizations and match organ and match locations, then when users are comparing data, it's a lot of work. And the value proposition is hypothetical, but the work is real. Right? And so people were saying, like, I don't have time. Like, yes. In theory, this could benefit me, but I don't have time to make all these subjective decisions about what would benefit me. And so what they found was, you know, they had a bunch of organizations that could collaborate, that had common interest in collaborating, that wanted to collaborate, but they didn't collaborate. And what we're wondering now is whether what we need is to actually build tools that promote responsibility, that remove some of the ambiguity about who is responsible for what, that essentially establish stewardship. Let me see. Right. So I could talk through some of these things, but but but the the the hypothesis that we're now working with is, like, if it's technically possible to compare all these records, at least at the level of the locations in the organizations, we the the real value may be in helping organizations determine who should be responsible for maintaining that information and establishing, like, a single source of truth or at least a representative source of truth. Right? A trusted source of truth, maybe not the single source of truth for information about services in such a way that organizations could, like, subscribe, maybe, if they just trust everything or maybe link their records if they wanna have their own way of describing a different, you know, a different subjective description to a different audience that might need different words. Right? Like, what we need to figure out is how do we strike that balance between responsibility and autonomy among these networks of collaborators? And if we can figure out how to do that in a way that actually makes their jobs easier, we will be on our way to solving this problem. But that involves various technical and political challenges that we're only just, like, starting to name. Z, hi, again.

Hi. I know. I'm sorry. I talked to Tanisha also. I spend a lot of time on this kind of problem, believe it or not. So Yeah. Thoughts and questions, honestly. So something that I've seen in shared data environments is having record level information about both source and destination. So, like, audience intended as a field and the actual steward itself as a field. This resolves to a bigger dataset often because you might have multiple entities maintaining a record about the same object because it's no longer a unique identifier, the entity. You're actually saying this entity cross with this steward who's maintaining this record crossed with the intent for this kind of audience. And that creates, again, a bigger database with a richer, unique record ID. But, actually, it makes it possible to, for example and and as an individual consumer application or or entity, you might prefer certain stewards that you trust. And, also, you might query against certain audiences and even different audiences depending on how you use it. So that's the hack that I've used in the past for shared data context where the consistency across the providers and the consumers is absent.

Z, you you've just made this hour worthwhile for me. Thank thank you for that. Because we'd we've reached the point of recognizing that if we wanna do essentially unique identifiers for this kind of collaboration, you can't just have a unique identifier that describes the service. You need a unique identifier for the service and the source. Right? Like so, like, the contributors need to be uniquely identified. So in a given database where you have data from different sources, each record ought to have an identifier that has, like, a compound of of the source and the and the idea of the of the record itself. And you're suggesting, at least for some subset of that information universe, you could also have an ID for the intended target, which is a really interesting idea that I'm gonna throw into.

And the thing is it doesn't have to be always used. There's a difference between having your schema support that and the people actually exercising it. So you as you might be that in some regions of your universe, like, there isn't more than one. But in the future, there could be more than one, and you haven't precluded it.

Yep. Okay. That's that's that's really interesting. Thank you. Yeah. And let's see. And Edward asked about main constraints as a project. I'd be happy to walk through those. Really quickly, upfront well, there's just, like, the natural constraints of just, like, inertia. Right? Of just, like, even if organizations recognize, yes. We you know, this isn't working for us, and, hypothetically, this sounds better. That doesn't mean they have the capacity to change things. Right? So that's just, like, a natural constraint of of working for change. And there's, like, cultural constraints of just, like, it's very difficult to get people to think clearly about governance and complex systems. And I think the discourse about human centered design and also some of the discourse about things like blockchain are unfortunately, like, feeding in to that cultural resistance to thinking about complex systems and infrastructure. Because, like, we're just used to, like, you know, the Steve Jobs style. It just works. Right? Like and and and and if we and if you're talking about things like, oh, we need to get the different database managers to talk to each other and to align on these things. Like, the savvy types in the room are gonna be like, is that user centered? Where's the user in right? Like, it's just like, we are we are we are trying to swim against the currents of of most technology development here, which is a huge constraint. Within the within the topic area, I also I didn't mention here, like, a like, a specific challenge is taxonomy. Right? In that, like, the categories of services. Like, I talked about how service description is is subjective. Like, within that is the problem of service category, and that there's many different taxonomies out there. There's one that's actually, like, the standard, but it's intellectual property, and it's highly technical. And describing categories in a way that's useful to users and also effective at, like, delineating in really granular ways is surprisingly difficult. And I'm looking for solutions for essentially mapping between different categorical schema. And I'm surprised at how little I found out there. And I would welcome any suggestions about, like, methods of coping with the challenge of, like, different and potentially valid categorical schema that need to be essentially translated across each other. Edward, I think you're you might be right that, like, you don't necessarily need a taxonomy for, like, maybe complex or maybe, like, really sophisticated search processes in certain circumstances. But what we found is that you do for practical purposes for a variety of reasons. First of all, in many search cases where people don't know what they're looking for. But, also, like, when it comes to governance, right, the easy way to divide up services for different intermediaries to be responsible for is by geography. Right? That's we've seen that happen. Right? That federation happening among organizations where they just divide up by geography. But if they wanna divide up within geography, they need to divide up by category, presumably. Otherwise, they're going organization by organization to make decisions about who's gonna be responsible for what. And if they have different categories, how do you get alignment on on those essentially different responsibility lanes? Right? And so and so this is a real challenge that we have to that we have not figured out how to even start coping with, and I would welcome any feedback about where to find those things. I know we're we only have a few minutes left. I saw Sneha, you I saw you had a raised hand.

Yep.

Yep.

Yeah. So this is and this is a a another aspect of the discomfort that I articulated earlier where I'm like, I don't actually know that I believe that, like, community resources and, like, the help that we wanna see in the world is neatly expressed in a standardizable way as, like, organizations that provide services. To your point, like, the service system that we have is is cruel. Right? Like, it's it's it's not only insufficient. It's it's humiliating. It it's it's nonsensical. Right? And there's all kinds of ways in which people get screwed by these systems that people who are outside of those systems assume are just, like, functioning government and government and effective charity. Right? And I do have a concern that if we we, like, just make if we try to, like, improve those systems or, like, put, like, nice faces on those systems and we actually entrench them, my initial impulse in all of this was to say, like, we we either we're gonna have some sort of total societal collapse, and we're gonna have to just start from scratch, or we have to muddle through from where we are to some sort of better future state. And I didn't see a way to muddle through to a service delivery system, a safety net that I actually do want to see without exposing the one that exists for what it is. Right? Without creating the context in which we can collectively know what are the services that we make available to people in need as a necessary precondition to then having some democratic influence over, like, how ought we make available resources to meet people's needs. Right? Like, that was my optimistic, somewhat Obama era theory of change is that, like, if we make like, if we establish democratic control over these information infrastructures, we could then potentially build the capacities for democratic control over the resources themselves, right, and improve the actual allocation of resources. I don't know if I still believe that eight years later. What I what I know right now is I'm like, I am actively preventing things from getting worse. Right? I am in harm reduction mode right now because if it wasn't for the work of open referral, this field would be carved up by two to three venture capital backed, would be Ubers and Lyfts. And it would be further ingrained into the health care sector, which we didn't even talk about, where it's just like health insurance companies just being like, we provided this Medicaid patient with a referral to a social service. Therefore, we will not pay for their health care. Right? Like, that's the business as usual that we are in the process of just preventing from getting even more fucked up. And I would love to recapture that vision of, like, open, effective public good information systems being, like like, generative of true democracy. Like, that's that's what I that's what got me into this. It's been dulled, right, over the last over the last five, six, seven years, and I would love to recapture it. So, yeah. Alright. I think we're out of time.

Yes. This has been absolutely fabulous. Plans to keep talking about. I wanna make sure we have a chance to have everyone on mute and applaud before everyone has to head out. So one, two, three.

Thank you for the chance to talk about this. I gained at least one solid promising insight about governance systems and hope to continue the conversation. Edward, it would be great to follow-up offline. I'm really excited about what's happening in The UK. So

Fabulous. And, yeah, continue the conversation. Many of us are going in seminar. I'll post the recording. Greg, thank you so much. This has really been one of my favorite seminars, and I'm so glad we had you.

Alright. Let's keep talking. I love I I love this community. Let's let's see where let let's see where this goes. Alright. Thanks, everybody.