 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer for Data Diversity. I want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss graph databases, benefits and risks sponsored today by StarDog. Do the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A panel or if you'd like to tweet, we encourage you to share highlights of questions via Twitter using hashtag DA strategies. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And just to know the chat defaults to send to just the panelists, but you may absolutely change that to network with everyone. And to open the chat or the Q&A panels, you will find those icons in the bottom middle of your screen to enable those features. And as always, we will send a follow up email within two business days containing links to the slides and the recording of the session and any additional information requested throughout the webinar. Now, let me turn it over to Naveen for a brief word from our sponsor StarDog. Naveen, hello and welcome. Thank you very much for the introduction. Hopefully you guys can see my screen. I want a quick introduction. The VP of product here at StarDog. StarDog is an enterprise knowledge graph platform based out of Arlington, Virginia. We're a VC backed company and been in the business for a little over 10 years. Happy to be here real quick. I wanted to take some time to talk a little bit about, you know, how we think about this market space around enterprise knowledge graphs and our ability to democratize data for analytics and AI workloads. We all know Gartner's continuously evaluating the market's landscape and one of the areas that they've really honed in on this notion of how to tackle with this growing volume of data and distribution across the enterprise, making it very difficult for organizations to exploit their data assets efficiently and effectively. And what they recommend and we certainly believe that this is the right approach when you're thinking about your own data architecture strategies is to adopt a semantic approach to your enterprise data. Otherwise, they certainly fully believe and we certainly believe as well. You and the large enterprise organizations will continue to face this endless battle with data silos. And we kind of drill further into what does that really look like, you know, at the data architecture level. There's still points of friction that continue to remain when it comes to sharing data and knowledge broadly right you think about breaking down the data architecture in terms of the culture you're trying to create the data culture, data models that you need to build to in order to serve the enterprise, the integration that is required in order to bring all this data together. The interrogation of that data and eventually the intelligence with the underlying data and the metadata, and how do you turn transform what are what I would say are traditional challenges with current architectures to opportunities so when we think about data culture, the focus sort of shifts away from big data to wide data that means you're not necessarily just worrying about collecting data you're also worrying about connecting data. And you're not just looking at an approach that is purely centralizing all of your data assets but working in ways that allows you to federate data access. And importantly, you're not just leaving this in terms of control with the handful of specialists, but broadly working on data sharing to enable citizen data users. And when you think about it from a data model perspective current current architectures kind of data models are tightly coupled and shaped by the underlying data storage infrastructure. And where the opportunity lies is really in this notion of semantic models right the semantic model that is abstracted away from the underlying data structure, which and then represents itself as business meaning, which means it's sort of more consumer driven rather than data consumer driven rather than data producer driven. So you're looking at it from that lens. And that way you have a business meaning attached to it, which enables at the end of the day this notion of data harmonization reuse and interoperability. When we look at data integration. It's really in this notion of well everything has to be solved by making physical copies of data in order to serve the needs of the business right so you end up creating these complex data pipelines, either ETL or ELT. So today, there are opportunities here to look at ways to virtualize access to data that limits data sprawl. Yes, we will never ever move away from ETLing but there are opportunities where you may have to take the right strategy. So when it comes to, you know, enabling the business for ad hoc data analysis or working with data that's in a source system that requires real time access to that information so you're looking at the fresh, freshest data possible. And, and frankly limiting the amount of complex data pipeline development that needs to go on. The same thing around data interrogation a lot of times data interrogation is sort of centered around this notion of you got to define your queries up front and those queries are optimized for performance based on the underlying data repository, where really the opportunity is to create this notion of a search driven data exploration, enabling more complex query processing by citizen data users in ways that they can self serve. And lastly, not but at least is sort of this notion of data intelligence right so what do we know about the data and oftentimes again in traditional architectures it's sort of this collection of metadata that's catalog inventory for passive analytics. You know it sits on the side with no association to the underlying data itself, and the opportunities really how do you connect that metadata through that semantic model with the actual data so you can kind of infer new relationships and drive intelligent to the foundation so with that, obviously, we get into this notion of what enables an organization to take advantage of those opportunities. An enterprise knowledge graph is exactly what is needed, because at the end of the day what an enterprise knowledge graph does that enables this flexible semantic data layer for answering complex queries across a diverse but connected data landscape, and doing so in the way it does is of course harmonizes data metadata and rules with a business information model. It limits data sprawl with federated data access to heterogeneous sources and enable citizen data users to self serve and participate in the data process itself right at the end of the day, you want to serve the business users and being able to independently work with data and gain the insights and drive the decisions that need to make to function within their organization their operation, whatever it may be. And to that extent, Stardog really is about delivering this enterprise knowledge graph platform, connecting data based on business meaning and providing this flexible reusable semantic data layer. We have customers across many industries again really our goal is to empower data citizens to make knowledge informed decisions. And if you have, if you have an opportunity, and the inclination to embark on a journey, whether it's an enterprise or otherwise, we certainly have some assets here for you to get started for free, gives you an early hands on experience in both in terms of learning, trying using an enterprise knowledge graph platform for a whole host of use cases that might be of interest and we have pre fabricated knowledge kits by domains by industries that you may even leverage to as a starting point if you don't want to bring your own data. If you are Databricks users and inclined to work within that kind of an environment. We also have a established partnership with Databricks so within your Databricks environment, you can look up the category called semantic layer, which is Stardog, and then certainly you can connect to us through your Databricks environment directly as well. I know I kind of rushed through this very fast and I look forward to the presentation here shortly and then of course come back and take any questions as we go into the Q&A session so with that I'll turn this over to Donna I think we make good time and we'll move along accordingly. Thank you so much. And thanks for kicking us off if you have any questions for Naveen you may submit your questions in the Q&A and he'll be joining us in the Q&A portion of the webinar. And let me introduce the speaker of the monthly series Donna Burbank. Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategy Limited where she assists organizations around the globe in driving value from their data. And with that, let me give the floor to Donna to begin her presentation. Hello and welcome. Hello, thanks so much. Always a pleasure to join this webinar always nice to see some familiar names in the chat and online. Thanks for the presentation from StarDog. Really, really helpful. So, for folks that are new to this webinar. This is a monthly series that we have been doing for several years now and we'll do again 2023. So, often is a question right at the beginning that I'm sure Shannon has been answering. Will this be recorded? Absolutely. And the nice thing about data diversity is all the previous topics are recorded and available, I think in perpetuity. So, if you missed any of the other topics earlier this year, we'll be touching on some of those like master data management and data quality as we talk about graph because they are all interrelated. And we do take advantage of that. In next month will be enterprise architecture and its relationship into data architecture and then person will be posting next year's lineup as well. So hopefully you can join us there. But what we are talking about today and that was a great introduction to kind of the topic and in ways you folks can get hands on. But yeah, you had to follow on from what Niveen was saying is that, you know, graph databases are cool because they do allow you to kind of quickly have that idea of an enterprise knowledge graph. We'll kind of talk about what that is. Understanding those key relationships between these different enterprise data sets. You know, you probably are using graph databases more often than you realize as a user. And things like recommendation and social networks, you know, they are kind of the driver of a lot of things we're kind of getting more used to. So we'll kind of go over what they are and how they can use and also what they're not right within a new technology. There's always that, you know, the penchant to sort of say, you know, we can do this for everything and tools are good for individual things. So I think a lot of folks that frequent this webinar tend to be sort of from that relational database background, which is, you know, as we've talked about in previous webinars that's still like 90% of the market if not more. There's nothing wrong with that, but there's also new tools. So, so hopefully for folks that have kind of grown up or live and doing a lot of work with that relational model. This presents kind of an alternative or augmenting of that relational model. So the way I like to think about it you might say what the heck is this. But with graph databases the way I think of it because there's so many different data based models or data approaches when I kind of almost have a mnemonic for each type and for me graph is sort of that thing relates to thing. The cartoons there, Dr. Seuss, but what does that really mean? I guess the fancy way might be some nodes and edges or vertices and relationships or whatever but literally it is kind of like your entity relationship diagram tables and relationships between tables but we'll talk more about that of how the relationships between data really help that, you know, there was a question in the chat about what that we mean by that semantic layer. And that really is sort of it and to get a little bit philosophical in this presentation because, you know, a lot of this is sort of the concept of what we're even trying to do with each type of database storage. One of the things that's nice about a graph database at least in my brain is it sort of mirrors the way we tend to think. We don't always think literally I know I don't. And you might say, you know, so I'm going to go visit Mary and then you think, oh, Mary has a brother and how does her brother doing is he's still dating Stephanie and when he crossed that boat years ago and boats are great and I like my boats and then if you're me it's like squirrel, you know, but things aren't linear when you're when you're distracted that's a negative and instead of that squirrel. The beauty of the human brain is that we do make those connections right because there's these interrelationship patterns and what's the difference here you have data right a boat is data, a squirrel is data and brother and family relationships but the difference here is those relationships between things if that makes any sense. And that's what's nice about graph because as was mentioned in the intro we don't always know those rules up front. And a lot of it is the discovering those patterns and overlaying different patterns on the data or that semantic layer mean one relationship here is those familial family relationships that Mary has a brother named john. Right, the other is might be you know, favorite hobbies, they like to ride boats and all the things around boats right the data is the same is still Mary and there's still a boat. But those relationships between them sort of was different if that makes any sense right the way I like to think of it I guess getting philosophical. There's different ways of looking at the world and this to me is almost more that relational database world right in the, you know, 1735 if you all view folks have to memorize this in school, kind of that idea of higher degrees or taxonomies. You know, the, you know, kind of memorizing the way we could create ways to group biological systems and we know I had to met what was a third grade or whatever kingdom phylum class order family genus species right and the idea back then was that if we could just put everything in the world in its box, we can understand the world and wouldn't that be nice everything seems so simple. And sort of as we learn more about the world and the world gets more complex, the kind of different theories, kind of around that are things like even chaos theory or right if you think of this idea of emergence, where if you follow this but in complex systems, the patterns arise out of the multiplicity of relatively simple interactions and that's kind of the Wikipedia approach may be a way of thinking of that is, you know, without getting religious or philosophical there's this idea of a snowflake, and there's certain patterns of snowflakes that sort of you can see all of those things in the lower left or snowflakes, but no one top down designed each snowflake and each one is different there's no sort of pattern of snowflake that's the same, where this theory is uses often a city planning, where I'm just thinking of my university where everything was built and very ordered squares and, you know, there was everything was right angles. And when people want to go to library that cut across that long because that was the fastest way was sitting planning they often look at those patterns of traffic music movement and build roads based off that. So to me, and you might be running one on earth are you getting out here Donna, to me that's sort of the difference between that relationship model relational database where it's still very valid I know I'm going to create a customer database with these fields. It's a customer can have more than one order, and we link customers orders through keys, and we've designed that absolutely still a place for that there are things and there are business rules in your organization that you must manage, just like Kingdom File and class order family gender species hasn't gone anywhere that's still very helpful we have the periodic table of elements that model is still valid. There's this new way of a bird's I might not know how all of my customers fit together. Are they families they have similar buying patterns. Are they committing fraud together. Right, and that's that new that flexible thing that an enterprise knowledge graph and that more that discovery or that emergence or discovering patterns in the data through those kind of first order relationships. In any sense I'm sort of feeling like I'm getting awfully philosophical but I think that is really a different way of looking at data that's different than that relational database world and I agree from the beginning ETL isn't going away. But there's also things we can add to that for different discovery patterns. In the graph database, it is more all about the relationships and their first order constraints that's kind of your semantic layer right kind of ironically in a way I'm going to quote, many of you may know Karen Lopez, you should think a relational database isn't about relationships is about constraints really, we call it relational database, but it's really about doing keys, you know a key that links a customer to an account. And also when you think of key value pairs that's not super, you know, that's not really what they are great at but at a graph database, you know, a customer is the owner of an account and kind of those verb phrases are sort of what it's all about. You know, we could have Mary and her brother, Mary is a brother of john or Mary is the boss of john or Mary, you know, is the enemy of john. The relationship are really key to linking your graph databases together and that's kind of what makes the graph so powerful. So, and again, I'm not going to get super technical here that the vendors, you know, as a star dog mentioned, you know, download it try it for yourself, lots of great training online, which this webinar isn't going to certainly not replace. But we're hopefully, you know, if this isn't in your, your, your paradigm or your way of working. It could be an interesting addition again it's not a cure all for everything I want to be careful of every new technology isn't the best fit for everything but it is a very powerful tool if you're not looking at it in your, in your company, or in your way of working it might be something you want to look at. So what are some of the use cases. Social networks, right we kind of we kind of hinted at that with Mary and her brother right so understanding we have a bunch of people in our database. You know who are the cool kids in the database people who are linked with Donna because they go on webinars and they talk about data. So if you've sad lonely people up in the corner who don't like data and they are not in my network is why would I have them in my network right, but that that is used all the time think of Facebook, a lot of that right how do we think of patterns or customer buying patterns. You know what are our patterns or what are think of it in insecurity and risk there's a terrorist and who are those people linked with that, maybe bad actor, right. So this idea of that social network approach which is all about the relationships is a really neat use case for sort of graph in that graph model. We're not all over the map in this presentation, but we were sort of used to that concept. If you remember maybe it's the old folks in the call the bacon number right what's here, how many degrees of separation are you from Kevin bacon. And, you know, that there's actually a website out there where you can kind of called the Oracle of bacon where you can actually see your bacon number and how far away you are from Kevin bacon. So here for example, Audrey Hepburn and famous actors, I've done a lot of great movies. You can say, okay, what's the, what's the bacon number for Audrey Hepburn. You'll see right away there's a bit of a problem. There's two Audrey Hepburns right this is more than one actress with the name Audrey Hepburn so which we're talking about So it kind of proves the point that data quality master data management metadata management is still important these graphs can be super helpful, but if you have the wrong name for Audrey Hepburn or can't can't kind of differentiate who's I mean, the power of the graph is you can kind of figure that out they're both in different movies. You know, and that sort of thing but you know you can't have these great powerful graphs when you don't have great data as the basis right but kind of maybe a fun example to kind of show both the power but also kind of some of the risks. Um, fraud detection, I kind of mentioned that so think of that in terms of you have online transactions that there's typically you know identifiers that you know I logged in at it with a certain user ID certain IP address geolocation credit card etc. And graph patterns can kind of help you detect some of that fraud right so I have one IP address that just suddenly had 17 or here seven of this example credit card transactions all within a few minutes seems a little strange. Is that a bot is that someone you know committing fraud. I mean, the every IP address that is more than one the one on the right just must be three people in the same family they're all shopping for Christmas at the same time, or the one next to that could be me with both my personal and my business credit card buying a couple things near each other, those might not flag anything weird but when you start to see massive, these kind of tightly knit, you know, graphs or kind of indicators of maybe we should take a deeper look into this right. So companies can kind of put some triggers in the place to say hey you know when this happens let's let's maybe do something about it. Recommendation engines, you know we're all sort of familiar with those I bought this you know would you like to also buy this when you're doing online shopping that can be powered by a graph database right because you know that this customer bought this product that does is a graph relationship to another product super powerful. You know again very different from maybe how you might use a relational database in terms of that power but that's definitely an interesting use case. As with everything though, there are, you know, it isn't a silver bullet you need good data quality. You also need good data volume so this was an example I was kind of going through. And then did, you know, I was on Amazon.com and then just pick something strange, an axe on the left, which actually followed me around on the internet because they thought I wanted to buy axes and it was sort of creepy. Different topic, but the recommendation engine I got was, you know, people who purchased this axe also bought coffee filters, which is a very strange recommendation it's really hard to see why on earth. You know, it's probably an axe to either split wood or kill people or do that. Why would that have any relationship to coffee filters right probably my guess is that that type of axe is used for camping. And those coffee filters are kind of some of the ones that people use when they go camping and kind of use that so you know maybe three people up in Alaska or Canada were kind of going camping and bought these and there wasn't enough of a data set to really the recommendation of here's other three kinds of camping axes that people might have bought or or a sharpener for that camping axe or something right. So in this case, the model is fine there's nothing wrong with the graph pattern, but the data set itself was flawed. So something to think about that of, you know, mall, both the data quality, or the being able to have that master data those those nodes be correct, but also having F volume to have this make sense, which leads me to master data management. Because I have whole rants about master data management often folks kind of talk about that 360 view, or really understanding all of that that's not master data master data of, you know, enables that master data is which Audrey Hepburn and I talking about, do we have her right name and do we have her right address right which enables the 360 view of all the great things about Audrey Hepburn, but it's not master data. So, this idea of a graph database is used in some of these solutions around master data management. But I just want to be a little careful that there's different ways to approach master data management. Refer you to the master data webinar we gave earlier this year and there's a lot of a lot of great resources on master data management, you know different models. So one model is kind of millions let's go for that centralized approach that typically is your relational database model. Say I want that hub and I want all my customers in the same place, and I want to create my matching rules, it's the same customer. If they have the same name and the same birthday and the same social insurance or Social Security number right. It's pretty important to get that right node. So if we're going to say push back to your operational systems right right once I've identified the correct Audrey Hepburn or Donna Burbank, I'm going to then go push back to all the systems. Once Donna changed her address and make sure all the systems are synced. You really want to get those matching rules and really get that, you know, down. But often kind of that idea that was touched on the intro, you know that virtualized approach, or maybe more of the analytical, you know, I'm not necessarily pushing back to all the source systems if I, if I just trying to see buying patterns of wealthy people. And I want to know, you know who Audrey Hepburn is related to. So we can target her friends to buy jewelry or whatever the rich people buy. And then you kind of want that that flexibility and it's fine to have that kind of virtualized layer across and it's more that discovery approach. I've seen customers kind of use both really well together of let's use something like a graph or that virtualization type approach to do discovery and see those patterns and even see you know who are top customers. And how do they link together, which kind of helps define some of those business rule patterns, and then they also went to more of that kind of relational mode of the, you know, the match rules and the match merge sync for the MDM. I'm not going to say one is right, one is wrong, they both have their, their benefits, but you know that MDM of trying to do those match merge how do you discover who's the who's the right Audrey Hepburn. That's kind of the hardest stuff that you have to get right before you want to get all of the benefits and stop you from doing a graph they can, again, it's a cycle, you can do the graph to do the discovery that might help you with some of the data quality, which is then going to start a graph so it doesn't mean you have to get everything perfect before you start a graph, you know, on the contrary, they can kind of be synergistic and help each other. So kind of, you know, in the title of this webinar we didn't want to just only sing the phrases of graphics to the benefits and risks. I think one of the risks that I touched on in the beginning is you know what's that phrase when you have a hammer, everything So data warehousing is, is, is something that's been around for a very long time. It's still a very valuable thing it's not a graph they have different use cases so data warehouses are still around they're not going anywhere. They're not the only tool in the toolkit. But if you are trying to aggregate and summarize data probably wouldn't use a graph database you're classic you know I want to report on product by sales by region by sales rep by whatever you're sort of describing a, a data warehouse. So that's a very different approach and they can work really well together for different use cases. You know I want to get my total sales by region by customer each month in 2017. You know, I think most folks in this call are kind of familiar with that approach sort of almost where diversity type webinars grew up and started and in the day because we've been around for a long time. We understand the source systems get the data quality from the source systems, do that ETL model it either relationally or dimensionally and then start to you know create your cubes and do the slicing and dicing do we even know how to calculate total sales. You know what do we mean by a region was a customer is a fiscal month or you know calendar month all of that is still super valid. Maybe I also want to add on a knowledge graph of who might be my most influential customers with the most connections, you know Audrey Hepburn bought a fancy watch. Now all her friends. I know she's not a lot of her friends would be buying that same watch. So maybe those are the folks I want to target or, you know, etc, etc. So, again, it's really a different approach and a really powerful approach to work together. It's really something to consider. This might be another odd odd thing. But I think data management and ballroom dancing what on earth is she talking about here. So I tried ballroom dancing a long time ago, and it's kind of what the teacher had said there was you know, first when you're just beginning dancing. You're just standing at your looking at your feet so you're not going to step across and step on your partner that's probably still where I am. And then when it kind of clicks. Maybe I've had a few moments of this, and you and your partner are just kind of in sync and you know you don't see the rest of the world room and you're just spinning around it's super graceful. Then when you're really good. In my life I got kind of knew what the person was talking about. Everyone is such a good dancer and they're all in sync and you feel like the whole room is kind of connecting and the music and you're, that's really where kind of that progression of data management again first you dance with yourself don't step on anyone, then you just with your partner, and then you're really it to me that sort of a graph database, maybe I'm the only person who would have put those together. But again, you want to get your data quality right I want to make sure it's the right Aubrey Hepburn or Donna Burbank's birthday is correct so you can all send me gifts. But then once you get that and then you can add things like the graph that's when you're starting to make those connections and really dance with the room right because there is so much data in these these various silos and different areas across the room and the more you can unlock that and do that idea of the enterprise knowledge graph. That's really getting to that next level where you're not hindered by having to, you know, step by step or link everything together with ETL. Maybe that didn't make sense but it sort of did to me and the thing of you know that opportunity of really getting that graph approaches that kind of enterprise dancing with the room. And it can present this holistic view of the organization through these relationships. So again, you can discover things this might be say I'm high net worth insurance company that ensures people like an Audrey Hepburn for her, you know her mansion in Aspen and her yacht and her, you know, she filed the claim because her windows on her yacht broke or something like that. And you probably really want to understand that customer what, you know, what assets they do on who they're related to all of that sort of those graph patterns and this might be something like Audrey Hepburn, you know, maybe I have a customer called Luca Dotti which was born in 1970, who's her son. And you might not have realized that without some of these these graph patterns or you know really again that's the, it's hard enough to get the right claims and the right dates of birth and all of that but really it's those those linkages, or that power of the graph. They can really help with some of that. So hopefully that made sense as well. I thought this would be helpful. If many of you know who have joined these webinars. We do global data strategy and diversity do a survey. It's been like five years now that we do this every year sort of trends and data management of who's using graph databases, unfortunately or fortunately the fact that there's sort of lower level of adoption than some of the others as I mentioned the number one and on the planet is still the good old fashioned relational database. Don't think that is going anywhere. What keeps me up at night is number two is spreadsheets so please stop doing that. Nothing wrong with a spreadsheet but really is not an enterprise data management tool. So again whether it's relational or on prem kind of relational, what you say on prem or cloud relational still kind of leads the way. But I think the idea one of the things I find interesting about this graph is the number of other options and again it's not an either or it's an and so yes you may be using an on prem or cloud based relational database doesn't mean you need to stop. But what can you use to augment that in a graph database, you know, back again to the beginning, you may have these silos of relational databases or data warehouses and kind of having that graph pattern to go across that and really create that enterprise knowledge graph the dancing with the room can really be helpful so but unfortunately right now it's only about like it's almost 14%. According to this this is kind of the diversity crowd are using graph databases today. So looking ahead and maybe kind of going into what people are looking at is definitely growing. So you'll see it jumped up much higher. So back to the top you know relational still atop I think more folks are looking to the cloud than on prem matches my experience, but you'll see graph database has jumped and over 21% of folks are looking at that so I'd be kind of curious anyone here in the call who might be here. So, or getting kind of some some thoughts on that in the discussion which I know folks are never shy. So interesting to hear kind of people's experience there I find what sort of interesting here spreadsheets did go down in the group I think that's just because people know and wants to admit that they're go forward strategies spreadsheets but some folks are honored honest here. Yeah, definitely not the, not the thing we want to see. In summer and we did kind of leave some good time for questions I guess I spoke even faster than I normally do. But again what's what's graph again with all the different things you need to keep in your very busy brain. How do I think of a graph, I often think it's that thing relates to thing and the idea that semantics or the relationships are kind of first class constructs in a graph database. So, interesting use cases for graph talked about a few of the idea of that that social network is kind of an easy one to think of in your brain because it is that thing related to thing or customer related to customer fraud detection recommendation. You know that that really that enterprise knowledge graph of linking everything together. And yeah, not as many people are using it. Now, I would say, get your hands on it folks like star dog, you know they're offering some free free stuff out there just to play around there's no risk. I think you know, if you're like me. It's nice to kind of know in webinars like this what's out there, what the possibilities are, but it doesn't quite click until you've actually done it yourself and gotten your hands dirty so I would take the vendors with their star dog or anyone else that kind of offers either these more detailed training. Now again this wasn't the how to of how to build a graph. It was more the, the why to. So again, I take up the vendor and they'll be on the Q&A as well. For that so do want to give a bit of a plug. Again, everything in the past was on on this will be recorded. If you want to catch it again. It's on enterprise architecture if you want to kind of join us for that. Totally blatant plug if any of this is of interest for you, we do this for a living until hesitate to contact us at global data strategy. And then without further ado, I'm going to pass it over to Shannon to open it up for Q&A. Just me who's not hearing it. I'm here dollars in the vein. Shannon still on. Shannon maybe anticipating you finishing a little later than you. Maybe that whole whole fast. I will read them often. Great. I hope I get permission from Shannon on that later. So the first one is, you know, is the knowledge graph used or suited for a referential metadata, more than for statistical time series data. So I'll pass that to you Naveen first. What are your thoughts on that. Yeah, I mean, look, we, we talk about this sort of in the context of knowledge graph being a database. But really this knowledge graph is graph based technology. So the modeling the semantic modeling is graph oriented. But the data does not have to be materialized necessarily and inside of the, the storage layer of knowledge graph. One of the benefits of an enterprise knowledge graph platform is you can leave data in place. So typically what we see clients with that, that kind of collect time series data tend to do those in one of their preferred big data platforms and pull time series data in a sort of almost like a virtual access, virtualized access and connect that up with other meaningful business concepts that helps them derive some useful insight. So yes, while, while from a materialization standpoint, it's better suited for referential or metadata, or even unstructured text based, you know, entities that you're extracting using NLP pipelines. But the approach people take with time series data is not necessarily push everything into the materialized view of a knowledge graph. But the benefit of having a virtualized access is that you can pull in the relevant time series data to answer a specific question that's connected with other ideas or concepts within the knowledge graph. Yeah, no, I would agree with that. I mean, I do think that benefit of the knowledge graph is that referential aspect of it. I think it's a good example that data could be an input by, yeah, I think if there's better ways to store raw time series for what you're trying to do. But yeah, the knowledge graph is that layer above it that helps you do that connection so I think Shannon is. Sorry about that really fast today I guess. No worries and I was just having issues you know it's you know one of those days. So, thank you for diving in and. So, can you share more about success stories using graph databases. I'll start and then I'll definitely pass it over. I've seen more and more in terms of I gave some I'm not sure when this question came in. Some of the examples I'm seeing kind of pharma suitable doing making a lot of use of graph in that again what is farm it's kind of about some of that discovery and there's just a lot a lot of volume of data. I don't necessarily know the answer before you kind of go out so I think in terms of industries looking at that I know that's one that I've seen a lot of folks kind of using this idea of the power of the graph but I'll pass it back to start I can see see if you guys have any that you want to share. Yeah, so we see the application of knowledge graphs for a whole host of industry use cases. Everything from life sciences pharma which you mentioned around clinical preclinical R&D to, you know, all the way to the commercializations we call it sort of a molecule to market as part of the primary where you even looking at it from a safety recall perspective research perspective, understanding the interactions between compounds and molecules and proteins and the makeup of the particular drug interaction of the drugs right so so that's a primary use with large large pharmaceuticals we also see this in the context of financial services working around operational risk. IT asset management use cases customer 360 and manufacturing is another big industry that's that's looking at implementing knowledge graphs for things like digital twin digital thread for supply chain product 360 below materials or against top ship from a from a safety recall perspective, understanding that we also see this in terms of models based system engineering NASA big client of ours or, you know, they're, we're part of their moon rocket launch. The same thing with the Raytheon you know working on the F 35 understanding the entire supply chain of the parts and the components that make up and the quality associated with the components that make up the the fighter jets. Yeah, I wanted to add one more thing as you were talking it was getting my brain going I mean, I found interesting you know we do consulting for a living and one of the reasons we started looking more at graph. Often was a customers that were sort of saying hey I was at company acts, and we try to graph and one of the things you know in addition to the use cases that we both mentioned was kind of that speed to market. And again, it's not everything you see you still have to do the quality and all of that but in terms of, you know whether it's a POC or something that goes into production I think that is the power of this discovery way of discovery is that just in terms of time to getting some of this insight. There's been really some positive feedback on that approach. Not often I jump around and change the order of the questions, but this question I think it's very much related to the current the question that you were just talking about you know what are the most common use cases for using graph databases and especially for an industry like government. Yeah, I mean I think we touched on some of the common use cases, you know the farmer the pat you know when you're thinking if you're trying to discover patterns. Fraud detection is one that was mentioned for financial services I think in terms of which area of government one is understanding citizen and citizen relationships. There's a federal government, you know, some sort of bad actor threat detection in terms of terrorism and things like that is a use of, you know, graph because you're trying to understand some of the patterns. But yeah, I'll pass it over to start off and what do you think. Yeah, in terms of government certainly the ones you highlighted model model based system engineering is certainly big. As I talked about the NASA and the Raytheon use cases, we also see cybersecurity is another use case both in the government sector as well as, as well as financial services, again detecting patterns right. So if you look at, you know, more on the health side of the government sector. You know you do see things like fraud come up quite a bit or just tracking patient data from a citizen use perspective. Integrated criminal justice is another use case we see quite often. Depending on the part of the sector of the government civilian defense intelligence, you will see different applications ultimately you kind of think about this from the standpoint of your so you're doing this sort of wide data connectivity right so you have data and silos and how do you bring it together and presented in a way that's meaningful to someone that has to take certain action or decisions. And the best way to do enable that is through this, you know, this creation of the semantic model that ties the underlying data together against this model that's abstracted away from the underlying data infrastructure. So in regard to what appears to be a low use of graph databases any thoughts on why this is the case and increase. Yeah, I mean I'll jump in and then super interested in what jarbock has to say, um, you know, also this was a survey from data diversity again I think a lot of us at the diversity kind of grew up in that role and are probably busy enough with that. I think as with any technology I found that in certain industries, it's much more common and I think it will start to play out. And again, I've seen similar pharma, there's a lot financial services there's a lot. Good point. I think that aerospace engineering with got a few customers from there that are super interested in or have already implemented graph. So I think it will grow over time it's also just, you know, there are certain use cases where it's good for a certain where it's not another area I've seen it. But the other thing is, I think, you know, I wouldn't be surprised for people, not folks who are building it but maybe using it without realizing it. Some of the master data management solutions or this idea of customer 360 in terms of vendors that are providing kind of pre built solutions are using graph behind the scenes. And maybe a case also that is more ubiquitous and folks realize they may be, you know, not the folks building it if they're on a data diversity survey but they certainly kind of embedded in other things but back to you maybe and see what you think. Yeah, I mean certainly look at the, the application of graph knowledge graphs in general has really skyrocketed over the last few years and gardener says that 80% of all data analytics. You will have a knowledge graph component to it by 2025, you know, which is, you know, within this one to two year range that you described earlier Donna. More importantly, we're now seeing new patterns emerge from a reference architecture if you if you're following the whole data fabric versus data mesh, a reference architecture discussion that has a knowledge graph component to it, primarily for the reason that you know you want to create some ability to create these knowledge centric domains in a decentralized fashion that makes data as a product, but then be able to combine that across domains as well so that you can answer some more critical business questions in certain certain areas where there is a demand to connect across domains as well right so data fabric architectures data mesh architectures are beginning to be deployed within knowledge graph semantic layer underpinning. Once the knowledge graph is established, how do you add new information, aren't there refactoring issues. You're not a static just as you know any other sort of analytics isn't isn't static so you want to you know keep refactoring over time and keep adding and you know I like that reference to the kind of the data data mesh and data fabric you know that that is the beauty of these they are dynamic, but I'll pass that back to start off in terms of your approach to keeping things fresh. Let's look again it's it's now I know we the title says graph database and one of the things we really push this notion that it's, you don't have to materialize everything into a knowledge graph. And if you do have to do that that's fine, you know, you still employ things like change data capture and triggers to push new information rights to to the knowledge graph but the approach we find that's that's that works best for a lot of organizations leaving data in place right so you kind of limit the amount of data sprawl and at the query time, because you've created this mapping to a virtualized source, wherever the data lives. You're actually bringing the data together at query time so you're doing it, you're doing the integration that compute time rather than in a storage layer right so so that way you always have access to the freshest data, in terms of, you know the queries that that you execute and when you execute them using a graph database for business reporting lineage any suggestions. I'm sorry could you read that one again. I'm using a graph database for business reporting lineage. Any suggestions. Yeah, that's an interesting because that's definitely the thing that relates to thing right. Yeah, so that's an interesting use case. Start up what do you. Yeah, no absolutely we're saying increase the utilization of an OS graph platform to support lineage types of reporting and applications inside the enterprise. In fact, many organizations have invested in a data catalog, somewhere in the organization and in terms that's the basis of, you know, sucking in metadata about data. You know whether it's a calibre or unity catalog from Databricks or elation or purview from Microsoft rights, or even glue from AWS so that's a great way to pull in a lot of the metadata associated with information inside the enterprise about the data. But ultimately what you're trying to do is connect the metadata the actual data so you make it more queryable and you tie it to a more abstracted view of the information that has business meaning and representation to people that want to ask the question right so data scientists can ask from a linear perspective. What's the source of the data can I trust it. These are citizen data users, I'm sorry can ask those questions. Data scientists can even leverage that to say, I'm looking to do some feature engineering around the particular machine learning model and I need some geospatial data where in my enterprise data landscape can I find that information. Right so being able to use that as that sort of knowledge catalog that sits on top of your source systems or on top of your existing data catalog is a great use case. Yeah, and you bring a good point and I think that was touched on the initial question as well is that metadata connections and metadata is data at the end of the day right so you know there's that whole meta level of using the graph, as well as linking it to the data so so many use cases it's pretty exciting stuff. What else is on the list. Yeah, I think we can spend a whole, probably a whole year talking about this next question but certainly a webinar based on your experience to what degree is maintaining consistency of data a challenge and would you elaborate. Yeah, I'll jump on it first and I kind of touched on it in the webinar and you're right this is probably a series of, you know, of webinars, just because well probably even more so because you can link all of the data together. That data has to be a good quality right if I'm linking, you know, customers together or interactions together, you know, that only works well when you have a good data. And as I mentioned before, do you have to wait and get that benefit. It is a cycle and you can discover a whole lot of patterns that may help you understand more about the data which can lead to more discovery to help you, you know, and implement that data quality or, you know, the interaction but I think having visibility is a great first step so I think data quality is an evolution. You definitely want to, you know, work on that. I'll go back to Navin's point as well. It is necessarily that everything has to be in the same place all in one big database to be consistent that idea of kind of that, you know, graph approach where we're adding this, you know, virtualized, if you want to say you know layer on top of it can help with that consistency but I feel like I'm talking in circles but it doesn't obviate the need to really have that data quality so you know it is a bit of both of you still need to work on the data quality those nodes the data you're linking. If it doesn't make sense you're not going to get much from the graph, but it doesn't mean you have to stop everything and put it in one centralized place to start getting that value so you know that there's still a place for that in some cases but I think they can play nicely in with each other, but curious what startup wants to add to that. I think I see this question two ways one is sort of this common with the semantic and at a modeling level right this sort of how do you get alignment and agreement on, you know, a customer means a customer and then borrow the semantic analogy so you don't have to have the same definition you can actually have have a semantic relationship to the idea that a customer can be someone else you know can be a supplier, a customer can be, you know, maybe a partner, but that definition has that semantic relationship, because they're all kind of type type of people. And then that definition can also be segregated by different or different parts of the organization, and you can have multiple lenses, looking at that information in the context of their way and their definition right so there's consistency at that level. Yeah, in terms of consistency of the underlying data itself, you know, I think that's a function of a bit of quality a bit of defining the data quality constraints associated with the data itself. Those can be again tied to the semantic model they don't you don't have to do this in mass without any context right data has to be fit for purpose consistency of data. You really don't know what to do what what consistency means so defining it and it's sort of in terms of what is fit for purpose for a given use and enforcing that through these data quality constraints is something and all this graph can enforce as well so. Yeah, that's a great great point I mean we often say you know the definition of data quality is fit for purpose, you know there's no necessarily right or wrong so that ability in a graph to add those different semantic layers of what might be right in the context of one relationship may not be so much in the other right so yeah that's a great point of kind of really being a hone in on those different use cases is super important. Let's start to facilitate one's ability to writing graph queries. Yeah, so we have a, because we emphasize this notion of citizen data user participation we are one of our applications called explorer has this ability to allow users citizen data users to create graph queries work visually. So like a visual design experience of a query that doesn't require any knowledge of the underlying standard called sparkle. So that's certainly one way we facilitate writing graph queries. Alternatively, we obviously have an ID so if you are more of an advanced user and want to write your own sparkle queries. We have an ID workspace you kind of right right away and create create as many graph queries as you want. And I think we have time for a couple more questions here we got about five minutes. So what's the biggest challenge in implementing a successful graph. Okay, I'll just start with dog's opinion on that first. You want to take that one. Oh, yeah, sure. The biggest challenge in implementing a successful graph. I think it's, it's oftentimes the, the first set of conversations we have is, you know, the companies or users are trying to boil the ocean and trying to come up with this perfect semantic data model description that will help facilitate all the information that a business needs. And they get mired in terms of, you know, the typical blocking and tackling you know what's a common definition for me and what does it really mean. You know, sometimes you get too wired into the, the standards to the point where you're defining entities and concepts that really have no meaning for the business but you're doing it because you're a purist in terms of your approach. You know, like, like everything you just said everything's a thing. Well, so let's start with a think glass and think and also be people and think and also be objects and thinking, you know, it has no relevance to financial services and the use case around, you know, IT asset management. So don't always think about this from a purist sense of approaching, you know, your journey on our knowledge graphs right just start with your minimalist aspects of entities and relationships that are needed in order to answer a question. And then you kind of build it's built from there right you can always add new classes and you not every class has to be mapped to the source so you can have classes with no instances of data, that's fine. You can add them over time you can add the mapping over time, but focus on on a given use case, and that will definitely yield the results that creates value for the business in short order, and eventually an implementation that's successful for the enterprise. Yeah, yeah, not agree that starting small I guess and one of my thoughts, especially for, you know, a lot of folks that grew up in a relational world that it is a different way of thinking and just kind of start with a great I mean I've had a lot of my clients have a lot of great experience with again that time to market and some value but it, it often seems like a new too big of a new thing to start with all the other things we've had. So maybe starting smaller, or I think the learning, I must say the learning curve is difficult, but the impression that it's yet another new thing to learn, I think stops a few folks but you know, again starting with the small use case is a great idea because I think it's a great thing to have in the toolkit. Yeah, and that shouldn't stop anyone because I was I was a little surprised at the low adoption as well because they are super powerful, probably something to add to your list this year of things to kind of explore. Right. Yeah. So, okay. I slip in one more question we've got less than two minutes here. How are controls built around arcs within a graph database and family relationships like you described in some examples if a is the mother of be is it possible to parse through the graph and reverse and say B is the son daughter of a what additional logic considerations are needed to formulate those modified relationships. And I'll pass that to start off first too as well. Yeah, and absolutely I mean they again the, they're, there's relationships you can infer so not everything within a knowledge graph has to be codified in in a in the semantic model right in terms of relationships so you can, you can have a relationship that says a is the mother of be, and then be perhaps has a certain age and so if a is a mother of be, then you can actually infer that be at a query time, you can infer the relationship between B and ASB being the son of a. So it doesn't have to be codified in terms of actually defining it in the model in sort of, you know, explicitly sorry, I was thinking about the word. So, so what that really means is a query time the notion of inferencing or reasoning, where you can apply on the graph, where you can say if, if a if there's an a relationship with a is mother be then you infer that be is the son of a, and you can create that relationship on the fly queries at query time. Great. I have nothing to add to that. Well, thank you both so much for this fantastic presentation but I'm afraid that is all the time we have for today's webinar. Thanks to start out for sponsoring today's webinar and helping to make these webinars happen thanks to all our attendees for being so engaged just again a reminder, I will send a follow up email by end of day Monday for this webinar with links to the slides links to the recording of this session as well. Thank you, everybody. Thank you Donna. Thank you, Naveen. Thank you. Appreciate the time and the opportunities so hopefully folks that have a good day. Thank you. Cheers.