Brad Bolliger: Pragmatic Semantic Modeling for Government Data – Episode 42

Brad Bolliger Brad Bolliger entered the knowledge graph space via enterprise software system design and data analytics. That background informs their pragmatic and strategic approach to the use of semantic technology in systems that facilitate information exchange across government agencies. We talked about: their work at EY (Ernst & Young) on data and analytics strategy assessments and enterprise software design and as a co-chair of the NIEMOpen Technical Architecture Committee how their work on EY's Unified Justice Platform introduced them to the knowledge graph world a quick overview of entity resolution the NIEM standard, its origin in the wake of 9/11, its scope, how it's built and managed, and how governments use it their pragmatic approach to ontology and vocabulary management the benefits of the extensibility of the RDF format and knowledge graph technology how entity-centric data modeling accelerates and facilitates systems evolution their take on "analytics enablement engineering" their approach to crafting AI-ready data and building AI-aware enterprise solutions some of the neuro-symbolic AI architecture's they have seen and implemented their call for more systems thinking and systems analysis to create more effective services that work together in a more ethical and effective way Brad's bio Bradley Bolliger (they/them) works in the AI & Data practice of Ernst & Young and serves as co-chair of the NIEMOpen Technical Architecture Committee, an OASIS open standards project for data interoperability. Brad assists clients across various industries with optimizing data platform ecosystems, enhancing customer relationships, and leveraging advanced analytics tools and techniques in their digital transformation efforts. In addition to designing data platforms and AI/NLP systems, Brad has served in lead analyst roles for public sector information system modernization efforts, including major contact center data ecosystems and integrated criminal justice system environments, the latter of which would lead to the development of the UnifiedJusticePlatform. Connect with Brad online LinkedIn Unified Justice Platform Video Here’s the video version of our conversation: https://youtu.be/8XCmF3qXv1E Podcast intro transcript This is the Knowledge Graph Insights podcast, episode number 42. When you have to account for the people and other entities involved in high-stakes situations, you need a system that delivers accurate, unambiguous information. Brad Bolliger does this in their work on EY's Unified Justice Platform. Brad is relatively new to the graph world and has adopted a pragmatic approach to semantic modeling and knowledge graphs, focusing on applying lessons learned in their extensive experience in enterprise systems design and data analytics. Interview transcript Larry: Hi, everyone. Welcome to episode number 42 of the Knowledge Graph Insights podcast. I am really delighted today to welcome to the show Brad Bolliger. Brad works in the AI and data practice at EY, the big consultancy in Chicago, and also helps co-chair the NIEM Information Exchange, the Info Exchange Network and standard. Welcome, Brad. Tell the folks a little bit more about what you're up to these days. Brad: Thanks for having me, Larry. I'm thrilled to be talking to you today. Yeah, I'm non-binary. I use they/them pronouns, and I work in the AI and data practice at Ernst & Young, as you said, where I do data and analytics strategy assessments and enterprise software design, things like that. I'm also co-chair of the NIEMOpen Technical Architecture Committee, which is an Oasis Open standard for sharing data in public services primarily, but for specification for developing information exchanges. And I'm working on semantics and software design more generally. Larry: Yeah. And you kind of not stumbled, but you had semantics thrust upon you in this new role, I understand, 'cause one of the projects you work on, I don't know if you're still working on it, was the Unified Justice Platform at EY. Can you talk a little bit about that and how it brought you into the semantics world? Brad: Yeah, that's right. It spun out of an assessment from a county government wanting to overhaul their integrated justice system, which was the collection of actors who collaborate or have this adversarial relationship to administer the process of justice in their jurisdiction. And because very often they're their own elected officials with their own budgets, they have their own software to fulfill their own functions. And that means that they are kind of inherently operating a distributed system, sending messages back and forth to say, "Hey, we booked this person into the jail. Hey, we've got this court date coming up. Hey, we're filing these charges." And they need to orchestrate complex operational processes across multiple software systems and multiple groups of people, again, kind of across jurisdictions or enclaves. And that was, of course, a really interesting systems analysis process that led to the development of a solution to this problem we were trying to assess, which we later called the Unified Justice Platform and is an event-driven architecture for building an entity-resolved knowledge graph as an operational data store programmatically as messages are exchanged between the stakeholders in the Enclave. Larry: Yeah. And you used a couple of words in there. I want to clarify for folks who might be new to them. The notion of entity resolution, the entity-resolved knowledge graph, I'll just point out that we met through our mutual friend, Paco Nathan, who works for Senzing, a company that just does entity resolution. And can you talk a little bit about entity resolution, how that fits into the needs of this distributed system and how you implement it in the platform? Brad: Yeah. Actually, I'll plug almost two years ago, we did a webinar with someone from Senzing and talked about the fundamental utility of entity resolution and relevance, I suppose, as a problem more generally. Entity resolution is essentially about creating, for me, is essentially about creating a high quality master index of whatever kind of data that it is that you're looking at. So in this case, we were talking about a master person index so that you have a more reliable picture of the same natural person, no matter which software system is representing the data that describes the person subject to judicial proceedings in particular. But thinking about entity-centric data modeling more generally, you got a different type of entity, you still need to disambiguate which location you're talking about, which person you're talking about, which entity that really is. And if there are different representations, different records that relate to the same underlying entity, that process of entity resolution therefore has this really broad systemic benefit to data management and data engineering in particular, because ultimately it's about the master index at the end of the day. Larry: Yeah. And as you talked about that, you mentioned that it's like this a canonical record of entities. And how does NIEM fit into that? Because that's a vocabulary as I understand it. Brad: That's right. Larry: Yeah. Can you talk a little bit about NIEM and how that works with entity resolution? Brad: Yeah, very briefly on NIEM, NIEM spun out of the post September 11th realization that public services needed to share data to collaborate more effectively to actually solve emergencies, but just problems in general. And what they realized was that they need to have a common language to collaborate more effectively. Again, because systems, machines, software systems, have this really concrete definition of we use these particular terms and they mean something in our enclave, but you could have a person's full name and a person's first name and a person's last name in two different records, but actually they're the same real person. So NIEM came out of an attempt to at least address some of that disambiguity. And what is most interesting to me about NIEM, honestly, is that it is a collaboratively defined list of vocabulary. So we actually get domain participants involved and they decide we use these terms and they mean these things. Brad: And so it's an attempt to reduce the amount of complexity that you could use to describe a different person, but communicate the same meaning without losing the information that's entailed in some data record. But I'm digressing a little bit probably. What NIEM is a framework for building message specifications, APIs, if you like, or other types of structures, data structures in general that is a community agreed-upon set of terms that have some kind of core relevance, person, entity, organization, or have some domain specific function, like, subject or something in human services and so on. Larry: Interesting. Yeah. And as you talk about that, that attempt to align people on vocabulary is such a notoriously difficult problem. And I don't know how many jurisdictions we're talking about here, but every little town in America has a police department and other social services that they do. What is the scope or the scale of that? And is it facilitated in any way by existing standards or vocabularies? Brad: Oh, very much so. In fact, the problem is even worse than you've described it very charitably, I think. Just in the United States alone, I'm told that there are over 18,000 law enforcement agencies, just law enforcement agencies. Nevermind how ... Anyway, so NIEM is a voluntary open standard. So it is something that is available, but is usually not mandated. There are some places where it is mandated for specific types of services. So the scale of the problem that we're talking about really depends on who's included in the conversation.