Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
With her 15-year history in the knowledge graph industry and her popular YouTube channel, Ashleigh Faith has informed and inspired a generation of graph practitioners and enthusiasts.
She’s an expert on semantic modeling, knowledge graph construction, and AI architectures and talks about those concepts in ways that resonate both with her colleagues and with newcomers to the field.
We talked about:
- her popular IsA DataThing YouTube channel
- the crucial role of accurately modeling actual facts in semantic practice and AI architectures
- her appreciation of the role of knowledge graphs in aligning people in large organizations around concepts and the various words that describe them
- the importance of staying focused on the business case for knowledge graph work, which has become both more important with the arrival of LLMs and generative AI
- the emergence of more intuitive “talk to your graph” interfaces
- some of her checklist items for onboarding aspiring knowledge graph engineers
- how to decide whether to use a property graph or a knowledge graph, or both
- her hope that more RDF graph vendors will offer a free tier so that people can more easily experiment with them
- approaches to AI architecture orchestration
- the enduring importance of understanding how information retrieval works
Ashleigh’s bio
Ashleigh Faith has her PhD in Advanced Semantics and over 15 years of experience working on graph solutions across the STEM, government, and finance industries. Outside of her day-job, she is the Founder and host of the IsA DataThing YouTube channel and podcast where she tries to demystify the graph space.
Connect with Ashleigh online
- IsA DataThing YouTube channel
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 24. One way to understand the entity resolution capabilities of knowledge graphs is to picture on old-fashioned telephone operator moving plugs around a switchboard to make the right connections. Early in her career, that’s one way that Ashleigh Faith saw the power of knowledge graphs. She has since developed sophisticated approaches to knowledge graph construction, semantic modeling, and AI architectures and shares her deeply informed insights on her popular YouTube channel.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 24 of the Knowledge Graph Insights Podcast. I am super extra delighted today to welcome to the show Ashleigh Faith. Ashleigh is the host of the awesome YouTube channel IsA DataThing, which has thousands of subscribers, thousands of monthly views. I think it’s many people’s entry point into the knowledge graph world. Welcome, Ashleigh. Great to have you here. Tell the folks a little bit more about what you’re up to these days.
Ashleigh:
Thanks, Larry. I’ve known you for quite some time. I’m really excited to be here today.
What about me? I do a lot of semantic and AI stuff for my day job. But yeah, I think my main passion is also helping others get involved, understand some of the concepts a little bit better for the semantic space and now the neuro-symbolic AI. That’s AI and knowledge graphs coming together. That is quite a hot topic right now, so lots and lots of untapped potential in what we can talk about. I do most of that on my channel.
Larry:
Yeah. I will refer people to your channel because we’ve got only a half-hour today. It’s ridiculous.
Ashleigh:
Yeah.
Larry:
We just talked for an hour before we went on the air. It’s ridiculous. What I’d really like to focus on today is the first stage in any of this, the first step in any of these knowledge graph implementations or any of this stuff is modeling. I think about it from a designerly perspective. I do a lot of mental model discernment, user research kind of stuff, and then conceptual modeling to agree on things. But when you get into this world, you get much more into the implementation side of going from a conceptual model into logical, physical models as well. Can you just talk a little bit first just about why modeling is so important?
Ashleigh:
Yeah. Modeling is the way that you put any of your data into context. If you’re looking at something as a human and you see a column of names, you can look at that and say, “Oh, I see that as a human name.” But you don’t know if they’re a customer, are they staff, are they vendors. You have no idea unless there’s a column header that tells you what that is. That is the most simplistic model, it’s a list.
Ashleigh:
That’s why modeling is so important is because if you don’t have any context to what this data is, and what it means, and how you should interpret it, it basically means nothing to you. Then you can misinterpret it and that leads to all kinds of problems.
Larry:
Right. One of the things we talked about before we went on the air was, “What are facts? What is knowledge?” Because ostensibly, that’s what we’re ensconcing in these systems that are built with these conceptual models that we come up with. How do you discern that stuff?
Ashleigh:
Yeah. If you look at a lot of us in the semantic space look a lot at Wikidata. If you look at Wiki data, these things are called statements. A triple that defines something and makes a statement about the world. In my mind, I come from a very deep scholarly community background where we’re doing a lot of research and you’re trying to find corroborating evidence. In my mind, when you turn a statement into a fact, it is when in that point in time, what is the overwhelming acceptance of a certain stance or statement in the world based on corroborating evidence. Now there are competing opinions about things. There are disputes, especially when you’re talking about scholarship. Some people, their findings are one thing, and findings are different in a different study.
Ashleigh:
But all of that comes down to is there enough corroborating evidence in one direction? When there are disputes, sometimes there’s nuance that has been added to the original statement where that original statement is still now true, it’s still accepted. But now, with this additional evidence, it gets even more nuanced, so you get more specific. You can really understand the nuances of that.
Ashleigh:
There is a half-life of facts, though. Because there was a point in time in the world where people, an overwhelming amount of people, thought the world was flat. We all know that is not the case. But at the time, that was a fact because there was no other evidence to support it otherwise. Or there was very little, or it wasn’t disseminated appropriately because it was quite some time ago. But that’s where it all comes down is can you defend? If you’re in a court of law, how do you defend your statements? How do you defend your argument? This is how scholarship has done things since the very beginning of time. Give me your evidence, go do some studies, and go and do some experiments to gather evidence to support your claim. That’s what a hypothesis is doing, is can you support your hypothesis? Can you disclaim it? That’s how you figure out what a statement and a fact is.
Ashleigh:
Then when you have that, how do you codify it so that it can be even more useful? That’s where knowledge graphs really come in because you can create it in a way that you can do inferencing. I know that’s a weighted statement nowadays. Unfortunately, it’s a weighted statement. Oh, actually, even saying it’s a weighted statement is problematic. I should stop while I’m ahead on that one.
Larry:
Yeah. Okay, we can change it. No.
Ashleigh:
Yeah. No, no. You can add in though that data governance aspect, especially if you’re using an ontology. There’s all these other aspects of why taking statements, and facts, and all of that evidence, and adding it into a system of record that you can then do other things with is really, really helpful, especially in this AI world.
Larry:
Yeah. That notion of system of record, for some people that’s enterprise lingo. I love that you’re talking about it. I love the academic and intellectual rigor that underlies your approach to modeling. I think a lot of the facts and knowledge that people are ensconcing in systems in the knowledge graph world, there’s just a lot of enterprise stuff going on. What are the facts, and evidence, and corroboration that you need? Like the classic thing that comes up in every conversation. When you say “customer,” what do you mean?
Ashleigh:
Yeah.
Larry:
How do you ensconce that organizational disparity in understanding of that term?
Ashleigh:
Oh, but that’s why I love knowledge graphs for this! You can have your data catalog and you can have your taxonomies. You can attempt to get everyone in your organization to agree on what a specific label means. In my practical experience, all those things are great and lovely. And yes, do those if you can do do those. Often times though, and this is what I learned very early on in my career when I was first doing taxonomy work, was nobody ever agrees on what label is used for certain things. Or very few. There’s always, “Well, there’s that exception to the rule in our enterprise and it’s super critical to our mission,” and whatever else it might be. So you have that going on.
Ashleigh:
That’s why I really love the very early examples where knowledge graph was used as a connector. I almost imagine it as those really old-school operators that would connect people with phone lines. You know, sitting there with the giant connector boards. That’s what I think about when I think of the early examples that I was using with knowledge graph, which is you have a node and it represents this concept. That concept can be represented by an ID, so it does not need interpretation. It is that is the ID. That is the UID, that’s what it is in your metadata registry of that ID. But then underneath that, you can have all the different people at your organization that might call customer a patron, or a user, or a player, whatever it might be. If those are different labels, you can just incorporate those into the equivalency node that you have.
Ashleigh:
Now you still need to do the effort of making sure that really is the same thing and there aren’t additional nuances. But that’s one of the very earliest reasons that people were looking at knowledge graphs is these meta-thesaurus kind of things. They’re incredibly helpful when doing that. Even in this AI space, that entity resolution has not gone away. We really need it desperately to make sure when you are using an AI out of the box, it’s not going to know what you at your organization, at Acme, Inc., or whatever it might be, defines as a customer. You have to have all that additional context for the AI to get it right. That’s where knowledge graphs are really important.
Larry:
Yeah. Again, before we went on, we were talking about it’s such a common thing now for the machine learning and the engineers to be excited about LLMs and all that they can do. It’s sometimes hard to convince them of the benefits and the need for the thing like the entity resolution capabilities of a knowledge graph. How do you get people on board with that? I know we’ve talked about a couple of obstacles you’ve hit.
Ashleigh:
Yeah.
Larry:
How do you get past those?
Ashleigh:
There’s two aspects of it. Before the generative AI explosion that we’ve all seen, that situation that you talked about was the norm. Okay, how do I really show the impact of an knowledge graph? There’s two huge mistakes that I hear from everybody that was saying that argument. “Look how cool this is! It shows you things that you would not otherwise be able to discover.” Unfortunately, if you don’t then tie that to revenue, or risk management, or something that affects the business, no one cars. I know us as data people care. We’re like, “Oh my goodness, look how cool! Oh, this is so cool! Can you see this? This is so cool.” Then you get the cool visuals and everyone’s like, “Oh! Ah!” Okay, cool. How much is that going to cost? Then that tanks it right there. You have to be able to show the real benefits of discovering that information. That’s number one.
Ashleigh:
But number two is trying to go up against the folks that are like, “Well, I can do that same kind of query in my relational database. I don’t need a whole different type of database to do all of these things.” That has all transitioned slightly now because of the new LLM stuff that’s going on out in the world where it’s so prominent is you can talk to your graph. You don’t even need to know it’s a graph database anymore. You don’t need to get their buy-in, you just have to show the relevancy of using this kind of structure to get at the information that you’re looking for. Or get at the inferencing, or do page rank, or community detection, or whatever it is that you’re doing. That is on the back end. You don’t even have to have engineers buy into that anymore, other than showing the ramification of doing this kind of activity for your business so that you get funding to do it.
Ashleigh:
That’s helpful. Where it used to be we had to be like, “Oh, now you need to know SPARQL, or now you need to know Cypher,” which is a little bit easier. Sorry, that might be a controversial statement. But from an engineering perspective, that’s how they think for the most part, from my perspective. You don’t need to know any of that anymore. You can sometimes just ask and the query is generated on the back end. These talk to your graph examples that are out there, you can still unearth what the query looks like once it’s created so you can trouble test it, which is important. That’s good.
Ashleigh:
But the other thing is I actually find myself in an opposite perspective now. Where I have engineers constantly coming to me over LinkedIn or from my YouTube. It’s like, “I now need a knowledge graph. How do I make one?” It’s like, okay. What are you trying to do with it? “Well, everyone says you need one now because it’s going to make my AI better.” Okay. Did you look at your data? Do you actually have data to support the knowledge graph for the use case that you’re doing? “Oh, I don’t know.” Well, maybe that’s a good place to look. How good is your entity resolution? “Oh, I don’t know.” Okay.
Ashleigh:
There’s this checklist of things now. It’s almost like sometimes I find myself in the position of not necessarily arguing against knowledge graph, but cautioning against just running headfirst into it. I am a strong supporter of go play, go experiment, get excited about knowledge graph. Those are all good things no matter how you come into it. If you’re going to use a graph RAG and you’re just going to get clay on the table, cool. Okay, go experiment. Go see some stuff. But you then have to understand how to take that experimentation and that fun thing that you were working on, and then transition it into real life.
Ashleigh:
That’s I think where we as the folks in the semantic space are really important in those conversations because we are the voices of reason. Where it’s like you are so excited, or maybe your stakeholders, your board of directors is like, “Oh, neuro-symbolic AI, we want to do all that.” Okay. But why? Let’s make sure we’re actually doing this for the right reasons because if not, it’s going to tank and then no one’s going to want to do it, and that sucks.
Larry:
Yeah. It’s great to have that enthusiasm out there. One thing, as you were talking it occurred to me. I do this search once a week, just out of curiosity. If you just do a search for “knowledge graph,” you’re equally likely to find Neo4j and other property graphs, as well as RDF-based property graphs, triple store kind of graph things. I know that you have done a lot with both and have talked a lot about how property graphs a fine way to get things started sometimes.
Larry:
How do you, as part of this onboarding … That list of starting with the why, what’s your business case, why are you doing this in the first place, that’s an excellent starting point. Probably close on the heels of that is this decision about which kind of graph technology is going to help me? How do you answer those questions? How do people guide them in that decision?
Ashleigh:
Yeah. First of all, if you listening right now, whoever you may be, are struggling with that, go look at my video literally titled Property Graph versus RDF Triple Store, or something [Battle of the Ages: Property Graph vs Triple Store]. It is one of the top videos on my channel to this day because this is one of the first questions that everyone always asks. I even did a little interview with Jesús Barrasa and Dean Allemang on this exact topic. It’s both, you can use both. You don’t have to pick. But it’s all about the use case.
Ashleigh:
If you need to really have that record of information, sourcing, data governance, making sure you know everything in everything about where all of your data came from, RDF is very good at that. If you need to use ontology constraints to build in some of that data governance, or if you are picking up data that already exists in some kind of graph form and now you’re like, “How trustworthy is this? How good is this data for my new AI case?” Well, guess what. Having ontology constraints will help you determine how clean or dirty your data is. Be prepared, it’s not going to be pretty. From my experience, it’s not going to be pretty. That is fine to have on that RDF side because you have all those checks and balances, and all of these different things that help you with that.
Ashleigh:
On the property graph side, they are fast. Now RDF databases are getting much faster, I’ll put that out there. There are some that are doing both. None of them do both together, as much as they might claim to be. Not pointing fingers anywhere. They might be. The folks that are trying to do that probably have the most promise of getting there, to the promised land of an RDF and property graph space. But honestly, you can still use them together.
Ashleigh:
It’s usually, what I’ve seen, is the RDF graph is the heavy duty, everything sits there that you need to ever have to compute, blah, blah, blah. It’s got all of these data governance rules, and the ontology constraints, and all the entity resolution stuff is going on there. Then the property graph is the swift river running across it. The bedrock is that RDF stuff, and then you got the swift river atop that’s, “Okay, I got to get this, I got to get this. I need a name graph real fast.” I need my AI to just dip in and dip out, and get my thing. Property graph. Again, not saying that’s the perfect solution for everybody in everyone’s use case.
Ashleigh:
Now if you have a pure analytics perspective on your use case, like a lot of cybersecurity things are maybe like this, where you just need your analyst to be able to do graph queries and spin up a graph to do that little mini named graph. Then flush it away, get rid of it. Property graph is perfectly fine for that. In fact, there’s new, newer I should say, graph databases that have come out that are not graph databases, nor are they databases.
Ashleigh:
It’s a way of just adding a graph-like layer on top of your relational data or other property graph data. Then being able to do a lot of those graph queries across things that you need that network to do. You’re just doing it for analytics. You don’t need all that extra stuff from an RDF. There might be an RDF graph somewhere with all that information, but you don’t necessarily need it for just that analytics. I’ve seen a lot of that showing up too because it used to be this monumental task, this huge project. Oh, now I need a knowledge graph and a knowledge graph database, I need all this other stuff. That’s going to cost this much, and it’s all this new extra stuff, and blah, blah, blah, blah, blah.
Ashleigh:
Taking away the barriers to entry is property graph. That is when when you do that Google search on knowledge graph, Neo4j and others like that are showing up at the top because they are fast, they are quick. You can get in. They have a SQL-like query language already.
Ashleigh:
I will tell you my one beef here, Larry. There are very, very, very few RDF graphs that have a free tier. That is causing a lot of problems. People ask me, “Oh, great. I want to try this out, but it seems like all these RDF graphs, I can’t even experiment with it unless I pay money.” I’m like, “Yeah, that’s sucks.” For anyone listening out there, please make one. Again, there are a few, don’t get me wrong. I don’t want to name-drop here. There are a few out there, but we need more. We need more of you all that already have RDF graphs to have a free tier so people can get involved in it. You will get more customers, by the way.
Larry:
Yeah. No, I’ve talked to so many people who, they get curious about graphs and they look around a little bit. The first thing they notice is Neo4j is like every SaaS product in the world, you just set up an account, start playing, and there you go.
Larry:
But as you were talking about this new hybrid. There’s already these hybrid architectures of machine learning and old-fashioned NLP, and all kinds of other stuff. That’s enough of an architecture already. But then you just talked about property graphs and RDF-based graphs together in the same architecture. How does this all get stitched together nowadays?
Ashleigh:
Oh. Well, again, not to say AI fixes everything because it does not, and sometimes it causes far more problems, so don’t get me wrong. But I have seen a lot of people starting to use … There’s two approaches to it. Where if you’re integrating with an AI where the graph is being used for grounding, or the graph is being used for entity resolution, or one of those flavors of things, it still needs to have a lot of structure to it for the AI to really understand.
Ashleigh:
Good example that I was just experimenting with yesterday. Anne Hathaway. I’m sure everyone listening probably thought of the actress that has been in stuff recently. But what I just learned yesterday was the wife of William Shakespeare is also named Anne Hathaway. If you were asking an AI, “Who is married to Anne Hathaway?” It would very likely default to the actress because that’s probably the most popular person that people mean when they say Anne Hathaway. But in my context, maybe I am not meaning that Anne Hathaway.
Ashleigh:
Making sure that your AI has all of that connective tissue to figure out which is correct when it’s doing that entity retrieval, when it’s then generating a response, is again, talk to Paco Nathan about this. Entity resolution is so not the sexy thing to talk about sometimes, but that’s the only way you can get your AI to understand anything in your data. If you’re using a property graph or an RDF, you need to make sure that that is a closed loop system on some of that stuff.
Ashleigh:
Often times, you can now get the AI to write its own queries into whichever database you’re working on. When you’re using a property graph, it’s usually you have all the nitty-gritty stuff going on in the underlying RDF. That’s where all the ETL drops things, that’s where you’re doing all the cleanup, and all of that sort of thing. But then, you have these named graphs that can get surfaced for whatever the AI is doing. Or if you’re using agentic search, it can then figure out which named graph it needs, and then it does those things for you.
Ashleigh:
There’s a lot more opportunity now. It’s not actually that different than an aggregated search from back in the day, but it’s more effective now. Although, again, caution, caution, caution, because agentic AI has its own issues. There’s a lot of opportunities with that though.
Larry:
That begs the question. As you said that, back in the day, whoever was doing the aggregated search capabilities in an enterprise. Whose putting these architectures together? I just dropped an episode yesterday with Jans Aasman who builds big, complex systems for people. He told me at least two different main personas that he deals with. Who do you see as these orchestrators of these hybrid AI architectures?
Ashleigh:
Well normally, if you’re talking about the folks that are on staff, they’re usually the enterprise architects, or whoever that might be at your organization. The folks that are creating the data pipelines, they may not be as familiar with AI. They may not be as familiar with knowledge graph. But they already know how the connective tissue works. Go look up, AWS has a billion different architecture diagrams on their website. You can go and check them out. That’s a pipeline, go look at any of them.
Ashleigh:
You can then see, okay. Well, which part … This is what the data architects or the enterprise architects are going to see is, okay, the ETL is going into whatever storage you have. Does that storage then need to drop stuff into the knowledge graph? Then the AI connects into both of those, because you have maybe vector stuff going on in one and you have knowledge graph going on in the other. It depends on how you’re structuring things, how you’re trying to connect your AI into things. Even if you don’t do AI. I’m so tired of talking about AI at this point like everybody.
Larry:
I’m sorry.
Ashleigh:
No, it’s not your fault. It’s just everywhere. Even if you don’t do AI. Let’s say you’re just doing semantic search, no AI. Okay, great. Now you can … We always talk about the integration with a knowledge graph database and all these other things. If you have analytics, it could just be feeding into your analytics platform, whatever it might be. You also can just do a flat, not say flat file, but you can just do a file export.
Ashleigh:
I know a lot of people that will take the, I hate saying old-school because I was around doing a lot of this, the semantic mappings between different terminologies that mean the same thing. Well, that’s how query expansion would work in search engines. You can still do that with your knowledge graph and export that, and then put it into your search engine for that query expansion.
Ashleigh:
There are still very valid reasons to use knowledge graph in semantic applications, in search, without having to go the full AI route. It’s really just working with those enterprise architects, it’s an architect of some sort, that understands, okay, what data is needed for the system I’m feeding into. What does that system understand? Does it understand graph? No. Oh, okay. Then maybe, if that’s the case, throw it into a property graph because then you can do some different queries across it. Or you just throw an API on top of one of these things. That’s where those architects are really serving and working.
Ashleigh:
I will also say that folks like myself, folks that are similar to me have probably seen a huge uptick in people reaching out and asking for consulting work on, “Well, how do I put this architecture together?” Even just in the blobby, architectural high level diagram. That happens a lot because again, it’s not the most common thing, it’s start to become more common. That’s where a lot of consultants are working right now.
Larry:
Yeah. God, there’s so much in there as you were talking. I realize with that question, I took us a little bit above our pay grade as modelers, if that makes sense. But I do think it’s relevant. That I think we all need to understand how it all is coming together because it’s getting so complex. You grounded us in, like you said, old-fashioned architectures, that it’s not really that much different.
Larry:
Hey, one thing I did want to ask about. A few episodes before this one, I had Jesús Barrasa on and we were talking about it. One of the things he talked about when I was trying to get his take on the difference between property graphs and RDF-based triple graphs. One of the things he said was the key differentiator in his mind was the level of abstraction. That RDF graphs are more abstract, which I think the more abstract you get, the more power that permits from a computational perspective. Do you have a take on that, or does that make sense?
Ashleigh:
It does. I think the way that I would put it … I respect Jesús. He’s up there with the top in my mind because he’s worked practically in both RDF and property graph. I feel like he understands in many different ways better than those that are like, “This is might camp,” whoever that might be.
Ashleigh:
But the way that I think about it is RDF graphs can still have a ton of granularity. It’s the difference between an upper level ontology versus a lightweight ontology. Yeah. If you just have a simple example of book title, authorOf, and then you have your author, it’s making that connection. I guess, the direction would be the other way around. You have the author, authorOf, and book title. Okay, cool. You can just do that and that is your ontology. To make a knowledge graph, you then populate it with data and that’s where that specificity still shows up.
Ashleigh:
Yeah, if you’re doing old-school this is your ontology, here are your instances. Yes, that’s how you would contextualize this. But in reality, the folks that are using RDF at this high scale, you could have thousands, upon thousands, upon thousands of entities that are defined by book title. Those are then going to be dictated by the ontology constraints that have been added to that node. And then that triple that you’ve created, what does that look like going forward in the constraints, and entity resolution, and all of those things that you can use that data for?
Ashleigh:
Yes. I think that the ontology is always at that higher level because it has to be to contain. That’s how I think about it. The node is a container of all the stuff that means that thing. In my mind, you still have all that same specificity. It’s just that container helps all the other downstream systems that has to access that stuff to do it better and more effectively.
Larry:
That’s resonating with the way Jesús described it as well. That’s super helpful.
Larry:
I can’t believe it, Ashleigh. We’re coming up on time already. This always goes way too fast. We have to have many more of these conversations. Before we wrap up, is there anything last, anything you want to revisit from the conversation or just want to make sure we share before we wrap up?
Ashleigh:
Just going into some of the themes that we’ve talked about here. I’ve referenced a few things that show up in that search discipline. Understanding how information retrieval works is so imperative and even more important now than it ever was before because that’s how you get the right, quote-unquote “right,” information, the right context, the right entity, the right fact, or property, or whatever it is you’re doing, whether it’s AI, or semantic search, or analytics. If you can’t retrieve the right information and you can’t get access to that right information, then you’re sunk. That information retrieval stuff is still pinnacle to how all this stuff works.
Ashleigh:
Even if you look at something as simple as LLM-RAG, there’s information retrieval in there. If you have crappy information retrieval, you have the best RAG system, but it’s going to do you no good because your information retrieval sucks.
Larry:
That’s great. Between you and Jessica Talisman, we’re going to just drag everybody right back into old-fashioned library science and IA stuff. Yeah, that’s awesome. Well, thanks.
Larry:
Hey, one very last thing, Ashleigh. I’ll definitely link to your YouTube channel. But if folks want to connect or follow you, how can they find you online?
Ashleigh:
Yeah. Best place is LinkedIn and my YouTube channel. My YouTube channel, I know you said you’re going to link to it. It’s just my name, even though it is called IsA DataThing. It’s doesn’t roll off the tongue when you type it, so that’s why it’s just my name so you can find it easier. Then, yeah, LinkedIn. I’m probably chronically addicted to LinkedIn. That’s my fault, but great for all of you if you want to connect me because I’m right there.
Larry:
I appreciate your feed, I’ll just observe, so thank you. Well, thank you so much, Ashleigh. It’s always fun to talk with you. This was awesome.
Ashleigh:
Yeah. Thanks. I’m so happy we got to talk.
