Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
Over his 20-year career, Jesús Barrasa has spanned the worlds of object-oriented property graphs and assertion-based knowledge graphs.
He knows as much about these two foundational technologies as anyone and offers pragmatic advice to help architects and engineers decide which approach will work best for their needs.
We talked about:
- his role at Neo4j in which he helps companies adopt graph technology
- his academic study of semantic technology and his early work on mapping relational data to ontologies and enterprise ontologies
- his move across the graph spectrum from RDF graphs to property graphs, culminating in his current role at Neo4j
- his take on the similarities and differences between RDF and property graph approaches, the key commonality being linked data and the key distinction between them being the level of abstraction that they employ
- different ways to approach inference
- the origins of the semantic web and how it has made data actionable and interoperable and smarter
- how the professional backgrounds of software developers can affect their choice of graph technologies
- the crucial role of interoperability in graph technology, and our ongoing inability to productively harness it
- how semantics is managed and used in the property graph and RDF worlds
- ontology as a technology-independent way of representing knowledge
- the importance of staying focused on the needs of practitioners when advising them on how to make a graph technology choice
- how knowledge graphs can balance the “opaque power” of large language models with “explicit, declarative, explainable power”
Jesús’ bio
Dr. Jesús Barrasa is Neo4j’s AI Field CTO and the company’s resident expert in Knowledge Graphs and Semantic Technologies. He co-authored the O’Reilly book “Building Knowledge Graphs: A Practitioner’s Guide” (released in July 2023) and combines over 20 years of professional experience in the data management space split between industry and research and academia.
Prior to joining Neo4j, Jesús worked for data integration companies like Denodo and Ontology Systems (now EXFO), where he gained first-hand experience with many successful enterprise-wide data integration deployments and large graph technology projects enhancing the operations and analytics of major companies worldwide.
Jesús’ doctoral work in Artificial Intelligence and Knowledge Representation focused on the automatic repurposing of legacy data as knowledge graphs. He’s an active thought leader in the graph and semantics communities and co-hosts the popular monthly webcast on knowledge graphs “Going Meta.”
Connect with Jesús online
- Going Meta webcast.
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 18. If you search for the term “knowledge graph,” you’re likely to get an equal number of results about property graphs and RDF-based graphs. Jesús Barrasa has been immersed in both of those technologies for more than 20 years. He takes a pragmatic approach to graph technology adoption, focusing on the needs of practitioners and on the ability of knowledge graphs to balance the “opaque power” of large language models with the explainable power of knowledge graphs.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 18 of the Knowledge Graph Insights Podcast. I am really delighted to welcome to the show Jesús Barrasa. Jesús is about as graph-ey a person as it gets. I got to say he has a 20-year background in this stuff. He’s currently the AI field CTO, Chief Technical Officer for the graph database company Neo4j. Welcome to the show, Jesús. Tell the folks a little bit more about what you’re doing these days.
Jesús:
Hi Larry. Thank you very much. I’m really, really glad to be here. I mean, we’ve been trying to plan this for a while now. Really, really happy to have this conversation today. So yeah, you’re right. I’m with Neo4j. And well, I’ve always been part of the… We call the field organization so we were not part of building our product, but helping our customers adopting it and adopting graph technology in the general case. These days we have a very, very strong focus on as it’s inevitable in how we integrate with large language models, GenAI, which we’ll talk a little bit about later on in the show but that’s what we do. So basically I work all over the globe with all of our customers, many of our customers of course, and helping them adopting graph technology. So that’s where I am today.
Larry:
That’s great. This show, I really like to focus on adoption and use and practice around graph technology and you know as much about it as anyone. I don’t always start these episodes with a biography, but your background is so interesting. Because I think virtually every guest I’ve had to this point comes out of the RDF-based, ontologically driven knowledge graph world. And you come out of that world originally, but you’re currently in the property graph space. So tell me a little bit about your pathway from your original study and your career.
Jesús:
Yeah, absolutely. And that’s going to age me I guess. But yeah, you’re right. Well, I started many others as a university graduate. I went on and I did computer science and started doing software engineering. But what it really starts for our conversation today is when I decided to join the, it was called the Ontology Engineering Group in Madrid and started my PhD. And that’s when I met these people that were using these super interesting technology that was called Semantics, the Semantic Web. Of course it was back in the day when Berners-Lee and company published the famous article in Scientific American.
Jesús:
And that was amazing. I really, really enjoyed it and finished my PhD and this was the early 2000s, so around 2008 or something like that. And what I did basically was coming up with a way of mapping relational data. I don’t want to go too nerdy too early in the conversation, but mapping relational data. Which is basically where all the data lived to ontologies. Basically overlaying some form of semantic description of the meaning of the data. And like many others we try to come up with a declarative, structured mapping language to be able to basically leverage in the semantic web the content from relational databases. So that was great fun. And that’s work that then later on people like Juan Sequeda, who we talked about earlier today followed and even built a company around it. But that’s what I did.
Jesús:
And then from there on, I moved to the UK to London to join a company called Ontology that’s still around under a different name that we’re using the RDF stack. And they were focusing on the telecoms verticals. So we were building connected representations of, I would say all the elements involving the delivery of a telecom service. I mean from the physical infrastructure to the logical elements. And the services, the products, even the customers. And we were trying to solve problems like impact analysis, root cause analysis. So we did that for a few years and that was again, great fun.
Jesús:
And that’s where I jumped to other side of the graph, let’s call it, camp. Or let’s call it spectrum, because more kind of a gradual thing. And a short stint at a data integration company called Denodo. Then I joined Neo4j. And I’ve been with Neo for the last nine years, so quite a while. Which means that I’ve been doing graphs for close to 20 years which is crazy. And like you say, I’m one of these unusual individuals out there that has spent as much time doing RDF and SPARQL as I have been using a property graph and Cypher, which is great. That puts me in a great place for conversations like this one. And it’s been great fun. So that’s kind of a bit of an overview of what I’ve been doing over the last over 20 years.
Larry:
And that’s really… Because the way you just said that you’re reminding me of, it’s just data. And you’re getting at it in different ways. You’re querying it with SPARQL in some cases in Cypher in another context. But as much about the distinctions or how to navigate that spectrum from property graphs to RDF-based knowledge graphs. How would you describe the similarities? If you do a Google search for knowledge graph, it’s a mashup of property graph and RDF-based graph stuff. How would you distinguish the two? And what unites them and what separates them, I guess?
Jesús:
Sure, yeah, I know, absolutely. And you’re totally right. So I don’t think we always do a great job at helping practitioner, which is ultimately what should be our main objective. So yeah, I mean the way I see it is they share the most important aspect, which is they have the same underlying abstraction, which is connected data. So we think of the world not in terms of tables or documents. We think of the world in terms of things connected to other things. Because that’s how humans think. So we think of Larry is a person, Jesús is a person and we’re friends and we’re connected through a friendship relationship and we work for companies. And the world is a collection of things related to things.
Jesús:
Now, if you go down the RDF stack approach you’re going to break down that into individual atomic statements that are called triples, which is what RDF is based on. And you would put it in your choice of model would typically, not always it shouldn’t be and we can happy to talk about that later, determine kind of a technology stack. But ultimately it’s kind of a level of abstraction. If you go the RDF route, you would describe it in terms of statements. So person 123 name Larry, person 123 lives in Amsterdam. Person 123 is connected to person 234. Person 234 is Jesús. So everything can be broken down into logical statement into triples. And that’s one way, that’s one approach.
Jesús:
And now there’s the property graph approach where instead of talking triples, we go up a little bit in the abstraction. And we talk, we call nodes. And the node is just a collection of triples that share the same subject. So we don’t no longer have a collection of triples that describe Larry. We have a node that describes Larry. And this node has an internal structure, which is a collection of attributes. So it’s essentially the same thing, but we work at different levels of abstraction. And then when you query things, you query triples on one side and on the other side you objects or nodes and relationships. So then there’s consequences of that.
Jesús:
And we can argue for… And I don’t think we should, but probably, and that’s my experience over the years, people tend to feel more comfortable talking about objects. And that’s aligned with why, because techies are aligned with the object-oriented approach. They understand the notion of an object, whereas breaking it down in triples might be a bit… I mean, not anymore for me, but that’s where kind of the difference is. It’s exactly the same information represented at kind of a higher level of abstraction or a lower level of abstraction. But essentially connected data, which is the most important thing. I don’t know if that helped or that kind of-
Larry:
That’s one of the clearest and most helpful explanations of the difference I’ve ever heard. So yes, that’s the short answer to your question. That’s very helpful. I guess, let me ask one of the things that comes up a lot in the RDF-based world is the ability to do inferencing and reasoning with OWL over RDF statements. So that’s often seen in that world as a distinction between the two in a way that… I guess, this gets kind of back to the problem you’re solving. What’s the use case you’re addressing? And do you need that capability? That’s one of the questions. But there’s also, can you do similar things with a property graph?
Jesús:
Very good question. Yeah, you’re totally right. Probably let’s try to understand what’s a knowledge graph and which are the parts in it. And yeah, the idea of inferencing and I would say it’s essential to it in the sense that in a knowledge graph there’s data, there’s facts, there’s, “My name is Jesús. I live in London.” But then there’s call it facts about facts or some form of element that will help me deriving new facts about what I already know. “Because I live in London, I am based in the UK.” Why? Because maybe someone will tell me that London is the capital city of the UK. And there is kind of an inference possible that when you’re in a city that’s contained in a country you are in that country. So this is the idea of inference. It is very simple. I mean, it is not rocket science.
Jesús:
Now you can do that in many, many different ways. You can use rules for that. And what I just described can be described in a sequence of very simple rule. Or you can take it to the next level, which is even more interesting when you have, not specific rules, but you have a general-purpose engine that will go and look at these kind of statements about statements that are what we call the ontology are built close to your data. So there’s different ways to do this inference, but I like to separate these two. So one thing is how we represent and capture data. And you can take one approach or the other. And then do you have an additional element? And we probably go a little bit into the territory of how that’s implemented. So you can have a triple store with or without an inferencing engine.
Jesús:
There’s companies that build inferencing engines that are store agnostic in a way. So this is yes to your point. That’s a very, very important element, but that’s kind of a separate element from the pure data storage and manipulation. So you can have an inferencing engine. I mean Neo4j out of the box, to answer your question and I’m focusing on the technology that I’m more familiar with, does not come with a general-purpose inferencing engine at all. I mean, we don’t support OWL inferencing. But I don’t want that to sound like a limitation, because for example Neptune does not support inferencing at all. So that’s why it’s important to understand what you capture in your data store, how you manage, how you manipulate data and what you do with it. And inferencing is one of them. We’ll talk about validation. There’s interoperability. So I don’t know, I have the impression that I’m giving you very, very long answers. And ultimately, so-
Larry:
No, it’s the perfect answer. I limit these conversations to a half hour, but this is where we would go if we did… I heard about this guy who his podcast he just goes as long as it takes eight hours. If we were going to do that I would definitely continue down that. But I think that’s super helpful. That distinction between what you capture, how you represent and capture the data and then what you do with it and how it’s implemented. That gets it kind of deep architectural decisions in organizations. Is that what drives the decision between a property graph and a knowledge graph?
Jesús:
Well, I think that is definitely one thing. If there’s a strong need to have this kind of inference you might want to use some form of inferencing engine. I think the first one is quite important. In my experience a lot is into the, “What do I feel comfortable…when I manipulate data?” And I love a quote here from Dan Brickley. He’s one of the pioneers in the W3C space. I think he actually chaired the RDF core working group for years. And he’s the person behind schema.org. It’s a funny one. He said, “RDF is defined like a model for data exchange, but what you do in the privacy of your data store is entirely your business.” And that’s very, very important. Because in a way, RDF, and going back to the days of Berners-Lee when they published the famous Scientific American article, it was all about, “Hey, the data out in the web is represented in a way that can only be consumed by humans through a browser. What if we put some structure there so that not only humans, but also agents?”
Jesús:
And look, we’re using it now the same term 20 years later. So the agents, so some kind of software will be able to take these fragments of information and do something clever with it. And they talked about, “They will be able to book a doctor’s appointment for my granny.” Or something like that. So the reason why I bring this up is that’s the driver. So we have to first make data actionable, make data interoperable. And that’s one of the angles that are important for ontology. So ontologies are yes for reasoning, but I would say mainly to help us speaking the same language. If we all describe the world according… I know that’s kind of a utopia, but if we all describe the world in terms of the same vocabulary terminology, then the communication would be so easy. But if there are parts, if there are canonical elements that we can share then that will simplify that. So interoperability is one element.
Jesús:
And then the other one is, “Hey, what if we put some intelligence in the data?” Historically, data was kind of the by-product of software. All the intelligence was in code. And the code operated on relatively dumb data in the form of simple tables. Now what if we put some of that business logic in the form of rules, in the form of ontologies closer to the data? I mean, if you think of it, that’s fantastic because then all these different systems that operate on the same data would have a consistent view, will all apply the same logic, will not have replication. So this idea of making data smarter. These are the kind of drivers, and that’s where everything comes from.
Jesús:
Then, “How do I feel comfortable manipulating my data?” Well, some people will say, “I come from an object-oriented programming. I understand the notion of an object and I feel more comfortable putting it in a property graph.” Fine. Some people will put it on a relational database. Fine as well. And some people will put it in a triple store. So that’s why I brought Dan Brickley there. He said, “RDF is this kind of glue that brings everything together, but what do you do internally? How do you manipulate your data?” It will be driven by your expertise, how hard it is for you to find an expert to build a team. I mean, there’s so many drivers that are not only technological. So that’s why I’m skeptical sometimes to go in and prescribe, “If you’re solving that problem, you should go with the triple store. If you solve the problem, you should go…” There’s no such thing as a siloed categorization. I mean, these are tools that are out there. And you should go and explore them and choose which is the one that’s going to help you. Again, a super-long answer. Sorry, Larry.
Larry:
No, and the way you said that, again it comes back to every enterprise is its own thing and everything is bespoke. Every solution’s going to be different. But one thing you said in there about the interoperability of it, and I can think that’s why you mentioned Dan Brickley, because the whole point of RDF was… Well, two things about that. One is that, and you mentioned the dream of a universal ontology, and that’s part of the reason the semantic web I don’t think ever happened. I mean it has happened, but behind paywalls in enterprises.
Larry:
So there’s that interoperability part of it, but then there’s also the actionable idea. What do you do with it? And I guess this kind of gets maybe at the notion that the semantic web has happened, but in LinkedIn’s economic graph or someplace like that where they’re doing that kind of thing. I guess how important is interoperability, I guess, both in intra-enterprise silo busting, but then also industry connections if you have supply chain stuff or things like that? Does that question make sense?
Jesús:
Yeah, it does. And there are initiatives. I mean, not necessarily always attached to the whole semantic stack, but I’ve done a lot of work in the telecom space. And there’s the telemanagement forum, which is kind of the organism that creates these kind of standard vocabularies around topology, around inventory. So yes, there’s always that initiative. And it’s critical because in any complex domain and again I’m going to use telecoms, because it’s the one that I’ve spent most time on. If you have a network discovery tool and you have an inventory tool, if you can make them talk, if you can integrate data, because in that space it’s exactly the same. I mean, you will have 25 vendors for the Ciscos, the Nokias. So if they had a unified way of exchanging data that will make it so easy for you to create cross-domain, all sorts of logic. I’ve talked about impact analysis, root cause analysis, but there’s so many others.
Jesús:
So interoperability is critical and still we are so rubbish at it. We keep solving it by giving all the freedom to operational systems to do whatever they want. And then, “Okay, we’ll go and integrate in some form of warehouse.” And then all the ETL-ing and all the replication. Both of us follow Juan Sequeda and how he talks a lot about how we should be introducing more semantics from earlier on, because it’s an investment that’s going to pay off over time. But yeah, that’s something that it’s an unsolved problem 40 years later. I don’t know, 40, 50. It’s something that we’ve been trying to solve unsuccessfully for so long, but it’s one that keeps us busy, I guess.
Larry:
Yeah. And I can’t remember, was it Dean Allemang says it all, “Say what you mean and mean what you say.” And I think Jim Hendler said, “A little semantics goes a long ways.” And I know those are both guys that Juan is fond of. But talk a little bit about how semantics is dealt with in the property graph versus the RDF world.
Jesús:
Yeah, absolutely. So like I mentioned before, let me put it, maybe use an example. I mean, semantics is again a super general term that now it’s being combined how the whole machine learning community talks about semantics, semantic search in an entirely different way. But semantics is how we capture meaning, how we capture what we mean by our data. And when we capture meaning in a structured way, we can use it in the ways that we were talking about before. So we can use it to derive new knowledge. We can use it to validate our knowledge. We can use it to capture to detect inconsistencies in our data. I mean, it’s not different from how it’s done in the RDF stack. So you have to have a formal description of your semantics.
Jesús:
And we have not invented any new alternative way of doing it. If you have an ontology you’re going to be able to use it in the property graph space. I mean, one of the great things about ontologies, and again this is probably another misconception I would say. So an ontology is intentionally a technology-independent way of representing knowledge. I still remember probably the most popular definition of ontology back in the day, and this is like 20 years ago when I was doing my PhD, from Gruber. I think it’s like a declarative explicit representation of a conceptualization. Basically what it says, “It’s explicit and it’s declarative.” Which means it’s machine readable. So if you give me a description as a collection of an OWL ontology with a collection of classes, with a collection of object properties, data type properties with domains, ranges. I’m going to be able to parse that. That’s what’s great. And I’m going to be able to use it in whatever my platform is.
Jesús:
And back to your question, how that’s used in the property graph space. Well, there’s so many areas where it’s true that we tend to focus in specific, let’s call it problems or micro-inferences. A very common one is you have taxonomic classifications of anything. So let’s say we’re in the content management, we work with big companies like the Financial Times and you can imagine that every article is annotated according to multiple taxonomies. So this is UK politics, which is European politics, which is etc, etc. Or let’s take the retail space. We work with IKEA. And IKEA as you can imagine will classify any product in the catalog according to so many taxonomies. This is classified by material. This is classified by vibe, by function. So when you classify it according to different taxonomies, that gives you many paths to work out similarity.
Jesús:
So two things are similar, because they have a common ancestor. UK politics are close to Spanish politics, because they’re both in Europe. So this is one simple measure of similarity. So how do I build into my system the fact that subclass of relationship, which is kind of the construct that you use to create taxonomies, is something that can be transitively navigated? So if an article is about Spanish politics, it’s also about European politics. Why? Because Spain is a subcategory, a subclass of. So this is a very simple rule to build in. So if you describe your subclass of relationship, and I’m not giving you a tutorial here on how semantics works, but that’s exactly it. So this is called transitive closure. So navigating transitively a relationship is so useful to do recommendation, to do enhanced search, semantic search based on taxonomies. It’s useful to do.
Jesús:
Let’s take it to the next level, ultimate beneficiary ownership. I mean, we have stakeholders in a company and you want to understand who’s going to be affected if this company goes bust. So this type of navigation is a simple logic that you can implement by saying, “Hey, my ontology described this subclass of relationship as transitive.” That means you can navigate it as many times as you like. There you go. So we have implementation for that in Neo4j. So it will not be a full-fledged OWL inferencing engine, but these constructs are built in and you can use them out of the box. And so the principle is identical. I mean, we’re not going to ask you to take your ontology and translate it into Neo4j. I mean there’s already a standard, so you might as well use it.
Jesús:
And shameless plug here, I do this Going Meta podcast or webcast, which is very different. It’s less conversation and more kind of hands-on. I mean, I’m a big fan of giving people, giving practitioners tools and recipes to go and experiment. So we do exactly that. You have an ontology that you created with Protégé for example and you want to use it to drive the construction of a knowledge graph. Boom, that’s how you do it. Because an ontology is declarative, it’s machine readable. And you can write a few lines of Python that will help you do that. If you want to do inferencing, that’s what you do. So again, I want to detach the principle from the implementation, because it’s exactly the same and is entirely valid.
Larry:
Yeah. No, that’s super. The way I came to this world is I’ve been a content modeler for 25, 30 years. And I realized it’s like thanks that I’ve been doing ontology work. And my deliverables have always been sort of an conceptual ERD, just like dots and arrow, dots and lines, nodes and edges, as well as sort of a draft ERD to classically a relational database, but it could work in any of these. I love that notion of detaching the ontology from its technical implementation. Because that seems like the whole point is semantics, is understanding, “What are we doing here?”
Jesús:
I want to go back really quickly. I’m curious the insights you had. What was that first job with the Telecom where you were doing? It sounded like a complete laundry list of every organizational activity that you were trying to ontologically understand. Is that what was going on there?
Jesús:
Yeah, I mean the company, it was called ontology. Now it’s called Expo after acquisition. But yeah, we’re using the RDF stack to capture information from wherever it lives. I mean, if you give us information from an Excel spreadsheet, we’ll take it. If you give us information from a relational database, from an inventory system. That’s what happens in organizations. Some people capture information in the most unexpected ways and they’re relevant to answer more complex questions. And if you break it down in triples, put in that case in an RDF knowledge graph then we will be able to navigate across and answer more complex questions. So that’s what we did. And it’s identical to the kind of problems that we solve with Neo4j. That’s what I mean. If we talk to a practitioner, I mean the similarities are much, much bigger than the difference between the two approaches.
Larry:
That’s what I love. I love François Scharffe alluded to that when he introduced your keynote at Knowledge Graph Conference last spring. And that’s what I love. And you and Juan have talked about this. It’s not about differences, it’s about bridges and connections.
Jesús:
And like we were talking about before the session is, yes we could. I mean, I could spend an hour talking to anyone from the RDF space discussing how one is better or richer or different from the other. But ultimately what we should be doing is helping practitioners and helping them. And these kind of discussions are not necessarily the most useful ones, but it’s important to have an objective understanding of what these two technologies are, what do they have in common, and how you can implement different things using two different approaches. So that’s my kind of obsession. So it’s not so much. Yes, it is. You do build bridges, because there’s value in an ontology described in OWL. Because that’s already out there. And then implementing using it in an EFJ-based implementation. But it’s not because I believe in that and my religion is to get people to adopt knowledge graph. I genuinely think that knowledge graphs help in loads of enterprise problems. And my job is to make it easy for people to adopt this technology. So we’re only useful if we help people solving problems. That’s the key, I think.
Larry:
Well, that’s why I was excited to get you on the show. I’ve been doing various kinds of podcasts like this for eight years now and it’s always about practice and practitioners and how can we do best by each other. So yeah, thanks for indulging me. Hey, I can’t believe it. I told you this would go way too quickly, Jesús. But before we wrap up is there anything last, anything you want to revisit from the conversation or any last little bit of information you want to share?
Jesús:
No, I think there’s one bit. And I think I don’t have to remind, which we didn’t get time to talk about, which is now we live in the world of large language models in generative AI. And I don’t think, like I say that we have to. Because something that people have sort of understood very naturally. I mean, it’s a time where, yes large language models are amazing and they’re doing things that we couldn’t even imagine only a few years ago. But we’ve all realized very quickly that these kind of power, sort of opaque power has to be balanced with some more explicit declarative explainable power coming from knowledge graphs. That’s what the most common, best sort of understood approach to grounding LLMs is.
Jesús:
And so yes, I would say I like to ask people to be curious rather than take a religious approach to things. I mean, the most interesting experiments, the most interesting results come out of curiosity. And sometimes rather than them believing. And sometimes we tend to be a bit noisy in some conversations in LinkedIn and other forums. If people took a more kind of curiosity focused approach I think we would get a lot more and we get a much, much better adoption of this technology. But yeah, probably the idea of how graphs complement, knowledge graphs complement and the idea of capturing explicit knowledge in an explainable way in the knowledge graph complements the power of large language models is where we are putting all our efforts these days and where I think a lot of conversations are going to be taking place in the coming months and years.
Larry:
Yeah, I love that, “opaque power.” I am going to steal that quote, because that’s a perfect way to describe the LLMs, but also, and then the transparency and the explainability of an ontological understanding of a domain. That’s awesome. That’s a whole other conversation. Well, I’ll have to have you back to just work that over. But hey, one very last thing, Jesús. If folks want to connect or stay in touch, what’s the best place to connect or follow you online?
Jesús:
I think the best would be LinkedIn these days. I mean, that’s where I try to be active. I mean, obviously depending on availability and time. But yeah, that’s probably the best way. So feel free to reach out and I’ll be more than happy to continue the conversation to listen to what you guys are trying. And that’s probably the best platform I would say.
Larry:
Excellent. I’ll put that in the show notes as well. Well, thank you so much, Jesús. This was an awesome conversation.
Jesús:
No, thank you very much for having me, Larry. That’s been great. And yeah, looking forward to the next one.
