Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
At Bloomberg, Tara Raafat applies her extensive ontology, knowledge graph, and management expertise to create a solid semantic and technical foundation for the enterprise’s mission-critical data, information, and knowledge.
One of the keys to the success of her knowledge graph projects is her focus on people. She of course employs the best semantic practices and embraces the latest technology, but her knack for engaging the right stakeholders and building the right kinds of teams is arguably what distinguishes her work.
We talked about:
- her history as a knowledge practitioner and metadata strategist
- the serendipitous intersection of her knowledge work with the needs of new AI systems
- her view of a knowledge graph as the DNA of enterprise information, a blueprint for systems that manage the growth and evolution of your enterprise’s knowledge
- the importance of human contributions to LLM-augmented ontology and knowledge graph building
- the people you need to engage to get a knowledge graph project off the ground: executive sponsors, skeptics, enthusiasts, and change-tolerant pioneers
- the five stars you need on your team to build a successful knowledge graph: ontologists, business people, subject matter experts, engineers, and a KG product owner
- the importance of balancing the desire for perfect solutions with the pragmatic and practical concerns that ensure business success
- a productive approach to integrating AI and other tech into your professional work
- the importance of viewing your knowledge graph as not just another database, but as the very foundation of your enterprise knowledge
Tara’s bio
Dr. Tara Raafat is Head of Metadata and Knowledge Graph Strategy in Bloomberg’s CTO Office, where she leads the development of Bloomberg’s enterprise Knowledge Graph and semantic metadata strategy, aligning it with AI and data integration initiatives to advance next-generation financial intelligence. With over 15 years of expertise in semantic technologies, she has designed knowledge-driven solutions across multiples domains including but not limited to finance, healthcare, industrial symbiosis, and insurance. Before Bloomberg, Tara was Chief Ontologist at Mphasis and co-founded NextAngles™, an AI/semantic platform for regulatory compliance. Tara holds a PhD in Information System Engineering from the UK. She is a strong advocate for humanitarian tech and women in STEM and a frequent speaker at international conferences, where she delivers keynotes, workshops, and tutorials.
Connect with Tara online
- email: traafat at bloomberg dot net
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 41. As groundbreaking new AI capabilities appear on an almost daily basis, it’s tempting to focus on the technology. But advanced AI leaders like Tara Raafat focus as much, if not more, on the human side of the knowledge graph equation. As she guides metadata and knowledge graph strategy at Bloomberg, Tara continues her career-long focus on building the star-shaped teams of humans who design and construct a solid foundation for your enterprise knowledge.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 41 of the Knowledge Graph Insights podcast. I am really excited today to welcome to the show Tara Raafat. She’s the head of metadata and knowledge graph strategy at Bloomberg, and a very accomplished ontologist, knowledge graph practitioner. And welcome to the show, Tara. Tell the folks a little bit more about what you’re doing these days.
Tara:
Hi, thank you so much, Larry. I’m super-excited to be here and chatting with you. We always have amazing chats, so I’m looking forward to this one as well. Well, as Larry mentioned, I’m currently working for Bloomberg and I’ve been in the space of knowledge graphs and ontology and creation for a pretty long time. So I’ve been in this community, I’ve seen a lot. And my interest has always been in the application of ontologies and knowledge graphs in industries, and have worked in so many different industries from banking and financial to insurance to medical. So I touched upon a lot of different domains with the application of knowledge graphs. And currently at Bloomberg, I am also leading their metadata strategy and the knowledge graph strategy, so basically semantic metadata. And we’re looking over how we are basically connecting all the different data sources and data silos that we have within Bloomberg to make our data ready for all the AI interesting, exciting AI stuff that we’re doing. And making sure that we have a great representation of our data.
Larry:
That’s something that comes up all the time in my conversations lately is that people have done this work for years for very good reasons, all those things you just talked about, the importance of this kind of work in finance and insurance and medical fields and things like that. But it turns out that it makes you AI-ready as well. So is that just a happy coincidence or are you doing even more to make your metadata more AI-ready these days?
Tara:
Yeah. In a sense, you could say happy coincidence, but I think from the very beginning of when you think about ontologies and knowledge graphs, the goal was always to make your data machine-understandable. So whenever people ask me, “You’re an ontologist, what does that even mean?” My explanation was always, I take all the information in your head and put it in a way that is machine understandable. So now encoded in that way. So now when we’re thinking about the AI era, it’s basically we’re thinking if AI is operating on our information, on our data, it needs to have the right context and the right knowledge. So it becomes a perfect fit here. So if data is available and ready in your knowledge graph format, it means that it’s machine understandable. It has the right context. It has the extra information that an AI system, specifically in the LLM era and generative AI needs in order to make sure that the answering that it’s done is more grounded and based in facts, or have a better provenance. And it’s more accurate in quality.
Larry:
Yeah, that’s right. You just reminded me, it’s not so much serendipity or a happy coincidence. It’s like, no, it’s just what we do. Because we make things accessible. The whole beauty of this is the-
Tara:
We knew what’s coming, right? The word AI has changed so much. It’s the same thing. It just keeps popping up in different contexts, but yeah.
Larry:
So you’re actually a visionary futurist as all of us are in the product. Yeah. In your long experience, one of the things I love most, there’s a lot of things I love about your work. I even wrote about it after KGC. I summarized one of your talks, and I think it’s on your LinkedIn profile now, you have this great definition of a knowledge graph. And you liken it to a biological concept that I like. So can you talk a little bit about that?
Tara:
Sure. I see knowledge graph as the DNA of data or DNA of our information. And the reason I started thinking about it that way is when you think about the human DNA, you’re literally thinking of the structure and relationship of the organisms and how they operate and how they evolve. So there’s a blueprint of their operation and how they would grow and evolve. And for me, that’s very similar to when we start creating a knowledge graph representation of our data, because we’re again, capturing the structure and relationships between our data. And we’re actually encoding the context and the rules that are needed to allow our data to grow and evolve as our business grows and evolves. So there’s a very similarity for me there. And it also brings that human touch to this whole concept of knowledge graphs because when I think about knowledge graphs and talking about ontologies, it comes from a philosophical background. And it’s a lot more social and human.
Tara:
And at the end of the day, the foundation of it is how we as humans interpret the world and interpret information. And how then by the use of technology, we encode it, but the interpretation is still very human. So that’s why this link for me is actually very interesting. And I think one more thing I would add, which is I do this comparison to also emphasize on the fact that knowledge graphs are not just another database or another data store. So I don’t like companies to look at it from that perspective. They really should look at it as the foundation on which their data grows and evolves as their business grows.
Larry:
Yeah. And that foundational role, it just keeps coming up, again, related to AI a lot, the LLM stuff that I’ve heard a lot of people talk about the factual foundation for your AI infrastructure and that kind of thing. And again, another one of those things like, yeah, it just happens to be really good at that. And it was purpose built for that from the start.
Larry:
You mentioned a lot in there, the human element. And that’s what I was so enamored of with your talk at KGC and other talks you’ve done and we’ve talked about this. And one of the things that, just a quick personal aside, one of the things that drives me nuts about the current AI hype cycle is this idea like, “Oh, we can just get rid of humans. It’s great. We’ll just have machines instead.” I’m like, “Have you not heard…” Every conversation, I’ve done about 300 different interviews over the years. Every single one of them talks about how it’s not technical, it’s not procedural or management wisdom. It’s always people stuff. It’s like change management and working with people. Can you talk about how the people stuff manifests in your work in metadata strategy and knowledge graph construction? I know that’s a lot.
Tara:
Sure. I think there are different aspects to it and we can choose to talk about either of these aspects. So I think first going to the AI aspect of it and the replacement of humans by AI. This conversation comes up a lot as well in the context of creating knowledge graphs and ontologies, because now they’re like, “Oh, LLMs can create ontologies, they can create SPARQL queries, they can, I don’t know, create SHACL shapes from your data. So why do we even need human? All of these are being automatically generated.” And the thing is it’s not wrong that they can do this, but it’s the matter of how accurate is this and how adaptable is it? How relevant is it to what you are really trying to do? So if you think about the human element, it’s really the human that brings the whole context, the creativity, the domain intuition, the knowledge to the building of these ontologies, even if it’s being done with an AI agent or with an LLM.
Tara:
So the LLMs can always start creating for you this whole initial basically model that you can operate from. But it’s really you as a human who know why this thing should be created. What is it going to be used for? What is the initiatives of creating it? And you have the knowledge both from an ontologist perspective, from a structure, as well as a domain expert to basically evaluate this model and say, “Is this really correct?” You have that domain intuition that’s like, this doesn’t sound right, so I need to tweak it. I need to train it. So this whole role of still role of training, role of evaluation, role of expansion, these are all very human elements that still exist in the ontology creation world in the context of LLMs per se. And whenever I say this, I always put a little quote and they’re like, “Oh, maybe I’ll change my idea in my comments in six months’ time.
Tara:
I don’t know the way AI is progressing.” But one thing I’m sure is that that human oversight is still going to be there, because who’s going to define the ask? What is the initiative that I’m creating this ontology for, that element of it? But also there is the other aspect when you think about the organization and you’re creating an ontology or creating a knowledge graph for, there’s a lot of other elements that play a role like what is the ecosystem you’re operating in? What are the legacy systems that you have?
Tara:
What is the quality of data that currently exists in your system? What are the different workflows and processes that are there? And what are the different people that you actually have to collaborate with? Work with? What are their opinions? How likely are they to agree on these common vocabulary that an LLM will come up with? They all have very different perspectives and they have very different views from how this model, how this knowledge graph is going to be used. And that’s still very human. They have clients who have different perspectives, there are clients or people who think or talk about things differently, and all those aspects needs to also be brought into this whole process of the ontology modeling or the knowledge graph creation. And I don’t think, at least as of today, any LLM has that capability to bring that human aspect into the process.
Larry:
Exactly. No, I love the way you articulate that too. And I’ve seen you talk a number of times about this, and you come at it from a number of different angles. And one of the foundational things, and the reason I wrote that blog post after KGC, was your pragmatism seems to be at the base of this. Who do we got to talk to get this done? And you just alluded to that in your last answer. But I’m curious, you talked, for example, the first part is just a new knowledge graph initiative just getting buy-in. And well, you need executive sponsorship. Can you just talk a little bit about that aspect of getting a knowledge graph project off the ground? Who’s involved at that point?
Tara:
So I think I usually say we start with the fact that, oh, knowledge graphs are great and we know about all the technologies that are out there and there’s so many great tutorials and books now talking about it, but when we actually get into the implementation phase or actually we want to bring this knowledge graph into an enterprise. There’s a lot of different layers that we have to go to. And you brought in the first aspect, which is literally the buy-in. And when it comes to the buy-in aspect, I like to think about it from the different roles that people have in an organization as opposed to necessarily saying, “Oh, the C-suite or the managers or the engineers or that.” But really what is the position that people take? So one of the roles or one of the positions is basically the decision makers.
Tara:
They could be the C-suite, it could be a different management, it could be a small company, so it could just be the owner of that company that you have to sell to. But those are the ones who basically sign the check for you to say, “Okay, let’s get started at the first buy-in.” And for those people, you really have to speak in the context of the business and the dollar values. Because you want them to show that whatever you’re doing is bringing value to the business. And usually value is either through dollar values or customer satisfaction, which again results in better dollar values, so business values. So that’s kind of the conversation you want to have with those people. And then you’re going to meet other people in different levels, whether it’s different managers or engineers or, I don’t know, other people that you have to work with, which can be skeptics.
Tara:
You would deal with a lot of skeptics. And it’s important to understand where does this skepticism come from. And it’s usually because of the unfamiliarity of these people with the technology and the fact that they’re not comfortable with, “Oh, this new thing.” And if it’s an engineer, it’s like, “How am I going to support this? Is it like now I have to learn a new thing? Or how is this going to work?” Or they’re resistant to change. And that’s a huge thing that you’ll see. Why do I have to change? I’ve been operating like this for a long time. Why does that I have to change? And I think for these people, it’s very important to do this whole knowledge transfer process and make sure they start feeling comfortable with the technology and try to speak again in their language.
Tara:
So it’s about knowing the audience that you have and making sure you take them along the journey and prepare them as opposed to making decisions in a silo and then going to them and like, “Hey, from tomorrow you have to make this change of how you develop things or how you see your data or how you model your data basically.” So this is the skeptics. And then there are a lot of enthusiasts, which is great. So you want to make sure that those people become your allies because they’re enthusiastic in terms of what are the new technology, they’re very willing to learn. So you have to find that crowd as well to make sure that that crowd is behind you and you also train them and be very transparent with them in terms of all the things that you are doing. And then there are the leaders, so the leaders in terms of the pioneers basically, especially when you are embarking on this journey for the very first time in an enterprise, a lot of people don’t feel comfortable to be the pioneer.
Tara:
They’d rather wait for some to see something that has happened and see it work in order to follow. So you need to really also find those people, and make sure to start projects with people who have that mentality of a pioneer so that you can have use cases implemented, or POCs implemented that will show the value to others to do skeptics or to even for the higher level buy-in and sign-offs. So this is the short version of how I see the roles of people as opposed to the position.
Larry:
Yeah. The way you just described that, it’s like that’s a whole other full-time job. All that people stuff you just described.
Tara:
Tell me about it.
Larry:
Exactly. No, and I love the way that you described. And for each of them, you require a different communication strategy and approach. And yeah, that’s really interesting. And then it keeps going. You’re not done with the people stuff after you’ve identified all those people. Because one of the things I really liked, and I think you used the same slide about this in both the Knowledge Graph Conference and Connected Data London, that star team that you put in there. Once you’re going, now you have this team. Can you walk us through, because those roles, it’s a whole nother batch of stakeholders at this point.
Tara:
Yeah, that’s true. Because I think this first breakdown is more from just the overall buy-in. So when you get the buy-in from the people and you get into the implementation, let’s say execution phase, there is a factor of knowing who to involve to make sure you’re successful from the execution aspect. And a lot of times we see that when we are talking about knowledge graphs and development and ontologies, people tend to create teams in silos, which are like ontologists sitting on their own and “Oh, I’m going to model your world. And create a perfect, beautiful theoretical ontology for you. ” And when this happens, a lot of times, and again, I will emphasize this, this is from a role perspective, not a person perspective, because some people may have different skillsets. So an ontologist who just like an ontologist’s skillset basically on its own is not enough for you to develop even the right domain model.
Tara:
You definitely need the subject matter expertise to be part of this development. So an ontologist will always work with a subject matter expert to do basically the implementation of the ontology itself. It might be that the ontologist himself or herself is a subject matter expert. So that’s why I’m saying it’s not about people, it’s about the skillset that I’m talking about. So in that sense, you will end up probably with a beautiful model of your domain that is theoretically perfect. But then the business might come in and they’re like, well, this is great, but it’s really not solving my use cases. It doesn’t answer the questions that I have. And that’s why when we always start with the ontology development, we’re mainly saying, “Oh, let’s start with the use case.” And it’s the thing for any sort of development of the software solution product, you always start with what’s the client’s problem?
Tara:
What are you really trying to solve? And I don’t think the development of ontologies or knowledge practice any different. You really have to start with the problem and the use case you want to solve. And that’s why business has to be involved from day one for you. So they need to be there to tell you what is it that they want. It translates for the ontology development into the concept of competency questions, as you’re very familiar with. So that’s the business side. So the business, the subject matter expert, which again, maybe they’re the same per person. And the ontologists need to have to be in the room. And when these people are in the room, what happens is that we have seen, I’ve personally seen many cases where we’re like, “Oh, okay, this ontology actually answers all the questions that the client is asking or the business is asking.
Tara:
However, when the engineering enters this conversation, they’re like, “I cannot support this. My infrastructure will not process any of this data that you’re putting there.” So that’s why another angle of that star team that I always present is really making sure that the engineers are also involed. They need to understand how they’re going to build a system that is able to process this. Also, the ontologists need to understand what is the right balance they need to have between theory and practice for their ontology to be useful throughout the pipeline and for serving the business. And the last part I always say is you need to treat your knowledge graph as a product point. And you need someone to oversee all of the star team together and make sure they’re working together, and defining the roadmaps with the build of the knowledge graph. Because usually the knowledge graph is just, again, in its own silo, not treated as a product on its own.
Tara:
And the beauty of bringing product in is not just from the organization of the team, but it also brings all the product development elements, which is if they bring in the UX team. They make sure that the design thinking processes are also in place. So they also bring a lot more with them when they are part of this whole star team. So yeah, I want to make sure that all of these people have their say. And again, this shows another aspect of the human part of developing an ontology. Unless you think your LLM can basically play the role of all of these people and look at things from all the aspects, you cannot really replace this starting. And they all bring in also not just their knowledge from just the business, but I also bring in constraints in the ecosystem, this underlying systems that we have from engineering and legacy systems, or how the business operates or risk policies and all that stuff needs also to be integrated, which these people will have knowledge about.
Larry:
Yeah. As you talk about that, well, first, I’m reminded you emphasize that these are roles, maybe not that one person might fulfill one or more of those roles, so the team is always going to be interesting. But also you remind me of two things. In ontology practice, many people approach it as this balance between bottom up and top down. And then in a lot of design and engineering practice, there’s this shift left thing, everybody needs to be involved earlier so that you’re making better decisions. Do those things manifest in these? When you mentioned the engineer going, “Whoa, we can’t do that.” How soon do you make sure you get their input, for example?
Tara:
Pretty soon, to be honest. So even if you’re starting with just doing a POC, you can spill a very small team with one engineer, one ontologist, just for one SME working together just to take a very small use case, business use case to solve. But the engineers will get a very good view of, oh, this is something that I need to be supporting. Even if it’s a small scale, they get a very good understanding of what they need. But I usually see it the other way around, which is more of the ontologists need to know that what are the constraints of the systems and that not always the perfect philosophical ontology model is necessarily needed for us to solve the problems that we’re trying to solve.
Tara:
So that balance between practicality and perfectionism of the theoretical model, I think that’s a very hard balance that the sooner you bring these people together in the same room and solving a problem, the less you’re likely to hit that point where, “Oh, I cannot use this ontology.” Or “Oh, my ontology is just sitting there on a shelf without any use case at the end.” Yeah.
Larry:
Yeah. No, as you talked about that, you’re reminding me, I can’t remember where we talked about this, but you said at one point that the implications of working at different levels of abstraction, and I think some of these roles and some of these activities, you’re sliding up and down this abstraction scale.
Tara:
Definitely.
Larry:
Yeah. And is this where the product ownership mentality comes in? Because the ontologist, we all see this all the time, they’re prone to go into academic land and build the perfect ontology. And everybody knows that dynamic. And so how do you level-set people on staying in the right level of abstraction in the moment?
Tara:
I think that’s exactly it. So the product person, because it’s a general rule of product, but you do translation between technical implementation and the business use cases. So what I tend to do is always to say that the ontologists are no different than the engineer. They are actually in the context of what we are trying to build, they’re part of the same team for me. They are implementing something that will be used by business, hence they need to be involved with the business from day one. This huge gap that usually exists between the ontologist and the business or even the client, it’s the thing that causes the most problem. So if you treat them the same way that you would say, “Oh, my engineering team would have to understand the use cases or client requests.” If you treat the ontology team very similarly, that this falls into a natural flow of, “Okay, these are the use cases, we need to solve for it.”
Tara:
In order to solve that, there are multiple components. One could be an infrastructure piece to be built. One is the ontology model to be built. And so on. So for the layer of governance on top of it, so there’s a lot of elements. But it all gets treated as one product being built for a specific client for a specific use case. Hence, requirements get defined when all these people are together as a team and understanding what should be done, what shouldn’t be done, what’s the right level of abstraction that you need to have for your model. And yes, product is exactly the person who will do this translation usually. It’s like, okay, this is what the client want. Now this translates to what I need to build both from the data side, modeling side, as well as the engineering side.
Larry:
I guess that makes sense in any kind of modeling-based practice, that grounding person. One thing you’ve mentioned several times the role of, and I know this is probably a whole two or three other podcasts, but I’m just wondering maybe some of the top level take-homes of working over the last couple years with LLMs and other kinds of AI besides our symbolic AI, are there any major, I don’t know, take-homes or lessons? I love that you keep your focus on people. And I think it’s clear from what you said that LLMs are not going to replace people anytime soon, but what are they good at? How are they fitting into your workflows?
Tara:
They’re good a lot of things, so I’m a huge fan of technology. So I think it’s actually one of the things I would say is this very important point is that you shouldn’t be resistant to new technology just because you think that it’s going to replace you as the work that you’re doing. What you should really be thinking as a human is how does this new technology change my role? And I think that’s not a conversation we have enough of. We are always saying that, “Oh, the technology is going to replace you.” But that’s not the case, that technology is going to change your role. So whether it’s a new skillset that you have to have or whether that you have to use your knowledge in a different way, I think that’s how we should be really thinking about it. And again, LLMs are really great in a lot of things always. Even prior to LLMs with ML has been really great in entity extraction, relationship extraction, building the initial relationships between concepts or even data mapping to the ontology models that we have.
Tara:
So we should definitely make use of this and there’s no doubt about it. We should be very agile as how we develop our product in order to include any new technology, any new advancement that could help us. But on the side, the human aspect is just that your role changes. You don’t necessarily just get replaced and goodbye. I think that’s the wrong conversation. It’s the right conversation is how your role changes. What is it that you need to do now?
Larry:
Yeah. Sorry, I keep waiting for the conversation to switch all the way back. My first exposure to knowledge management was I met Doug Engelbart back in the mid ’90s in San Francisco. And just him talking about the whole purpose of this whole arrangement is to augment human intelligence. And I’m like, “Let’s do more of that.”
Larry:
But hey, Tara, I can’t believe it. We’re coming up close to time already. These conversations always go way too fast. But before we wrap up, is there anything last, anything you want to revisit from the conversation or just make sure that you share before we wrap up?
Tara:
Yeah, sure. I think we talked about a lot of different things and you’ve been in my talks, there’s so much that you can talk about when it comes to the development, and especially with the human blueprint. But I think one thing that I would very much stress on is what I mentioned initially is I don’t want people to think of knowledge graph just as another database or knowledge representation is just another database in a company. I want them to really treat it as the true foundation of their knowledge and information for the firm, for the enterprise, for the company they’re working on. Because at least for the foreseeable future, no matter how much advancement we make on the AI side, the interaction methods might change with your data. But the fact that the data needs to be there, it needs to be clean, it needs to be understandable and contextualized doesn’t change. That’s your goal and you need to really treat it as whole. That’s why, again, with the DNA comparison, makes sense here as well.
Larry:
Right. All the way back around, I love that.
Tara:
Oh yeah.
Larry:
Yeah, the foundation of this whole thing. Hey, one very last thing, Tara, if folks want to follow you or connect online, what’s the best place to find you?
Tara:
I think LinkedIn would be the best place. People feel free to email me as well. My work email at Bloomberg is traafat, R-A-A-F-A-T, at bloomberg.net, but I would say messaging on LinkedIn would probably be the best way to get hold of me.
Larry:
Great.
Tara:
Even though I’m not super consistent, but I try to be.
Larry:
No, I know you’re a busy person, and we’ll all honor that and acknowledge that.
Tara:
I appreciate that.
Larry:
Well, thank you so much, Tara. It’s always fun talking with you, and this was a particularly good one, so thanks.
Tara:
Thank you so much, Larry, for having me.
