The future of AI in the Enterprise: Entity-Event Knowledge Graphs for Data-Centric Organizations
* Talk from Connected Data London | September 2020 Online Meetup *
To support ubiquitous AI, a Knowledge Graph system will have to fuse and integrate data, not just in representation, but in context (ontologies, metadata, domain knowledge, terminology systems), and time (temporal relationships between components of data). Building from ‘Entities’ (e.g. Customers, Patients, Bill of Materials) requires a new data model approach that unifies typical enterprise data with knowledge bases such as industry terms and other domain knowledge.
Entity-Event Knowledge Graphs are about connecting the many dots, from different contexts and throughout time, to support and recommend industry-specific solutions that can take into account all the subtle differences and nuisances of entities and their relevant interactions to deliver insights and drive growth. The Entity-Event Data Model we present puts core entities of interest at the center and then collects several layers of knowledge related to the entity as ‘Events’.
Franz Inc. is working with organizations across a broad range of industries to deploy large-scale, high-performance Entity-Event Knowledge Graphs that serve as the foundation for AI-driven applications for personalized medicine, predictive call centers, digital twins for IoT, predictive supply chain management and domain-specific Q&A applications—just to name a few.
A talk by Jans Aasman
CEO, Franz Inc
You can listen to the podcast below:
If you are more of a visual type, you can also watch the presentation
Transcript:
00:00:00.150 - George Anadiotis Well, welcome, everyone, to the second who are second to talk today. The theme is as you as you know, enterprise knowledge graphs and how they can be used towards a knowledge economy. Our second talk is given by Jans Aasman, who is the CEO and founder of Franz, which also sponsored today's Meetup, and is going to talk about the future of AI in the enterprise and how entity driven Knowledge Graph can be used for data. I could say a lot about his background and where he's coming from.
00:00:39.660 - George Anadiotis He's one of the most prominent people in this space, but rather I can let him speak for himself and just just minimize the time. So the floor is yours.
00:00:50.640 - Jans Aasman OK, and then a quick question, George, do I turn off my camera?
00:00:54.720 - George Anadiotis I think it's on video. At least I can see you normally. So I'm guessing everyone else can as well.
00:01:00.900 - Jans Aasman But do you want me to turn it off? That's what it's you. I guess you have a slide deck that you're going to use.
00:01:08.940 - Jans Aasman So it's going to be in the way, OK? All right. No need to turn off the camera.
00:01:14.820 - Jans Aasman OK, then I'll start now on second.
00:01:25.770 - Jans Aasman OK. Setting a timer here. All right, let me go to my screen and you have to tell me if you see my screen, do you see my screen right now? George, you see my screen, yes, yes, it's perfect. OK. OK, well, welcome, everyone. So I'm going to talk this morning about. It's nice to is the morning here in the. In California, I'm going to talk about the future of AI in the enterprise, and I'm going to talk specifically about what we call entity event Knowledge Graph for data centric organizations.
00:02:08.900 - Jans Aasman So quick about a company where a private company, probably one of the few graph database companies that headquartered in California and our main product is AllegroGraph, a semantic graph database. We built and Knowledge Graph for our customers and we have a long history in artificial intelligence complexity. So that's all I'm going to say about our company. And then the key message for today. Yeah. Is so you're in the audience and you're probably already building a Knowledge Graph or you want to build a Knowledge Graph you.
00:02:45.110 - Jans Aasman I'm not trying to convince you that you need to build a Knowledge Graph you probably here because you're interested. Now, one of the things that we saw is that most people, when they start, they basically copy the complexity of their relational databases in their silos and copy it in a Knowledge Graph and then it's still hard to deal with the data. So our key message is that you can manage the complexity of all the data that you have by using our entity event model so that you can make at least two orders of magnitude easier to understand your data.
00:03:20.360 - Jans Aasman Or two queries and feature extraction from machine learning or retrieve, a 360 view of your core entity in just a few milliseconds.
00:03:29.450 - Jans Aasman Now, I know I haven't explained what an entity event model is, but I'm going to do that in a number of use cases that we've done over the years. And then i hope it becomes clear what we actually mean by this entity event model. First, we're going to talk about the telecom news space. Where we are, we looked at how you can build a Knowledge Graph for CRM, and that's where we first got into this issue of identity events.
00:04:03.390 - Jans Aasman And then we've been working for the last four years with a big hospital in New York called Einstein Medical College in New York Hospital, where we really deeply went into how you create entity event models. And now we're actually using it also in a call center in Atlanta. But we do many other projects in the industry. But these are the main use cases I want to talk about. So what have all these clients in common? Well, the first thing is they all believe in the dream of a data centric organization.
00:04:37.280 - Jans Aasman So in most companies, you know, there's a business problem. So we need a new application. So you get your new application, you build a database to support it, and then you link it to every everything else in the company and you have created another silo. People, the dream of the data center organization believe that you should have only one data platform and put all your applications on top. So applications come and go, but your data stays mostly the same.
00:05:07.720 - Jans Aasman Yeah, the other realization is that what people have in common is the realization that 95 percent of all sort of data is event data around one or two core entities in a hospital it would be a patient. And in telecom it's the customer and in a bank, it's a customer. Sometimes it can be a product, but because you see that all your data is actually events, you can actually also structure your data as event objects. And that makes your life many, many times easier.
00:05:37.960 - Jans Aasman And then finally. But what these clients have in common is that. Every Knowledge Graph you see by now uses natural language processing to get an insight in what actually happens in unstructured text and what they do also to try to start well, they build learning Knowledge Graph by adding machine learning and feeding the results of machine learning back into the Knowledge Graph. So you get learning systems. So that's what they have in common. So let's start with the first use case where we developed an entity event model. So we were with this telecom company, wanted to build a CRM system and they wanted something.
00:06:18.320 - Jans Aasman They are so in general, what happens is customers call in about the problems and then the agent is looking at least 10 systems to figure out what the problem might be and then and then finally come up with a solution and it might take multiple calls to get to a solution. So they wanted a system that already anticipates what users are calling about and then automate access to the required information to make it easy for the agent to find the diagnosis and the information and even guide the agent with how to make a decision, how to help the customer.
00:06:56.840 - Jans Aasman Yeah, and in practice, the system really eliminates system and agent diagnosis time, and it makes the handling of calls way, way, way more consistent. And both the agent and the customer were way more happy with that particular system. Yeah. And so with this Knowledge Graph, you do many, many things. When I call the call center, it already knows the three most likely reasons why I was calling the call center, maybe my bill is way to high suddenly, I lose connections to often, I don't know how to set notifications.
00:07:29.860 - Jans Aasman So they figure that out already. They know the last ten things that happened to me. So when I call they already have a list of those. They know if I'm a really good payer and so they help me instantly. I'm a really bad payer and you get to the back of the line or they also want to know if I call this this guy on the on the fence of switching to another. Let me let me help him as soon as possible.
00:07:52.320 - Jans Aasman Yeah. Or you can do many other things like social network analytics on your data or even know where your customers are daily and then do interesting things with that. If you want to build a system like that, the old fashioned approaches like business intelligence don't help you at all. I mean, a business intelligence system can tell you all about an average customer, but only a Knowledge Graph can tell you about the individual.
00:08:18.320 - Jans Aasman And so my customer wanted this 360 view of everything. With respect to the customer and the people that we were working with were really incredibly experienced Oracle users, they have been doing Oracle and Telecom for 20 years.
00:08:38.830 - Jans Aasman So they knew what they were doing and they knew that building a new relational database on top of all the other databases was a no no. And so they started by doing an experiment and they got this idea that they wanted to use a graph. And they started building these graphs from the data, but they quickly realized that they were actually copying the complexity of the relational databases into the Knowledge Graph into their graph. So that didn't help them at all. So then we got to this this crucial insight that if you look at all the data, you squint, look at all your data, then you actually see that 95 percent of all data is events data.
00:09:18.830 - Jans Aasman That is, people making phone calls, people paying a bill. I'm not paying a bill, people activating a phone, people calling to the call center to complain about something. But everything is an event. So the idea was then why don't we just make one event object that we use for everything or an event object is just a simple thing with the type like a call to the call center is always a start time, sometimes in time, sometimes location, and then just a few additional key value pair to describe the events.
00:09:49.850 - Jans Aasman But the shape of the data becomes incredibly uniform. And so we had the system, we have the system where you can have all these different systems, relational databases, email other CRM systems, network information. And you turn everything into an adjacent object that goes into the object here, and then every time when there is an event for a particular customer, the decision engine will call up everything they have about the. A customer from the database put it in memory, run a bunch of inference rules, even a basic belief network, to predict what actually might happen with the customer.
00:10:34.430 - Jans Aasman They put all the data back and maybe do some actions. And then because they have all of this, they can take all these events and start creating business concepts where the business people can do something with. So this person, John Smith, might have a genuine propensity for 80 percent. He's got this particular plan and you can see to what extent he fits with the plan, how often he had dropped calls. Anyway, this is data that is important to the business people.
00:10:59.960 - Jans Aasman So that was the first time that we really dealt with entity events and it worked out incredibly well. So then four years ago, we started working with a big hospital in the Bronx, Montefiore. Where we also created a Knowledge Graph to do any type of analytics you can think of, and it's heavily sponsored by Intel and also by HP because they think it's a it's a great effort to have something like this start within a hospital itself. So not an external AI company wants to do something interesting with hospital data.
00:11:38.390 - Jans Aasman But actually, if this is something that is done in the core of the hospital and so we have this one Knowledge Graph, yeah. That you can use for any type of analytics, we started in 2017 with respiratory failure model, I'll say a few words about in a minute that got the attention of management. This was still not very much a core process, but then they could also use the exact same data, shape and data model with all these events to do stepsister's detection.
00:12:13.870 - Jans Aasman And they could take a team of about 20 people and no longer use them for for going through records to see if a patient might have gotten sepsis, but actually had use the same data structure in three weeks time. They had an application that is way better than what human beings can do. But the same data structure can also be used to say to outpatient appointments or regular business intelligence. So. This have been this this is something we've been doing now for several years.
00:12:45.890 - Jans Aasman And well, let me tell you more about the what the what we do underneath all of this. Yeah. So let me first of all, talk about one use case. So the first use case that went to production was this predictive model for respiratory failure on top of a Knowledge Graph where this model can detect respiratory failure. Up to 48 hours before the event, way faster than doctors and nurses, and this model uses forty six complex variables where the doctor doesn't have time to more than three or four variables in these variables are pretty complex, like give me the largest difference between the value of serum calcium level and the midpoint, nine point five in the range of 20 for the last 24 hours.
00:13:29.760 - Jans Aasman Yeah. So I mean, if you're a doctor, so what you see here is scatter plots for each well, 16 of the 48 variables that we use in the model and the blue one is the mortality, the chance of mortality. And he here's the data elements. And so you see for each kind of data, like for the heart rate or age or weight of glucose levels, sodium levels, there's a different shape. So no human being can put it all together.
00:13:58.620 - Jans Aasman But I can easily do this anyway. So this is in production to the extent that's even used in the hospital. And this is typical. EFIC screamed at the biggest hospital, the biggest hospital enterprise system. Yeah. And now when our random force model says, hey, the value is too high, then it will actually ask a human being to make a decision like the system says, hey, you're at risk. And then the doctor can say, well, it's not my patient or I disagree or whatever else the doctor might decide.
00:14:34.170 - Jans Aasman But anyway, yeah. So this system is in production. So if you look at this, you could look at it as an effort to create a real mature data fabric in a hospital where you really want to be at the top, where you can use one platform for any kind of analytics, where you can have personalized medicine, descriptive analytics to cost of care. And of course, you always start with your silos. And if you're rich enough, you can pay and enterprise data warehouse with four thousand tables, twenty thousand columns that no one in his right mind will ever do data analytics on that.
00:15:14.220 - Jans Aasman So people build data marts. Yeah, but if that was too complicated. So here we also, just like with the telecom use case, came up with this idea. That. We need to use the entity event model so you can look at all these databases in hospital and kind of see that. It's actually all events - a person checks and checks out, gets a test, does the procedure, gets the medication administration sensor reading for final sign, an interest in enforce a bill payment to.
00:15:46.090 - Jans Aasman Putting this in relational tables is just pure madness, but making it simple, but putting everything into event objects and hanging off the core entity, which is the patient, makes it certainly way easier to do to understand to date and do queries with the data. Another point we did this is also important for every Knowledge Graph that we build is you need to have a good terminology system and especially in health care is incredibly important that you use the same name for the same thing.
00:16:16.220 - Jans Aasman So the hospital worked on a combination of medical and life science for coverage, taxonomies. It all integrated in one. And then. So it and it all goes together with this event model, and I'll show you that in a minute how that works and then because the ultimate model in the Knowledge Graph is so simple, the ETL becomes also very simple, becomes extremely easy to take any value in any of your silos. And map it to an event with its correct attribute and you're in business.
00:16:49.770 - Jans Aasman And then in this Knowledge Graph, you also want to use external data sources because this is all semantic technology becomes extremely easy to put in a database or an adverse reaction database or a weather database or a census database to see if people live in a poor, in a rich area, et cetera. And then this is so much data that you have to store it in a distributed, symmetric graph database. So we've done that and then ultimately we did all of this so that we could do our data science on top of all the data.
00:17:22.650 - Jans Aasman So we now have a whole slew of things. When it comes to data science, most importantly, declarative semantic description of data frames to automate retrieval of features from graph. So think of it this way. Instead of all these data scientists hoping to write SPARQL queries to get features out of the Knowledge Graph. Created a system where you just say in Python can specify the feature should feature factor that you need for your machine learning, but just creating a bunch of python dictionaries, adjacent objects where you specify the name of the variable, some other parameters.
00:18:03.220 - Jans Aasman Yeah, give that to this this just this data frame system and it will automatically do the queries for you. So anyway, that is the majority stack and so. Continuing, so I talked about how everything rests on that entity event model, so in the core features are entity and events are represented as hierarchical trees. Yeah, but we also group entity entities and events together. So for people familiar with semantic technology, so think of it. You have.
00:18:40.410 - Jans Aasman A core entity with events is simply a fancy touch, you get a tree. But what we make sure of is that the fourth element of every triple industry has the patient identifier so that because of our indexing technology, we can easily said, hey, give me all the triples, all the knowledge you have about this one patient. It takes a few milliseconds and you get everything, you have a completely secure view of this particular patient.
00:19:05.350 - Jans Aasman And of course, all of this is terminated into a knowledge base. So how does it look like this is a picture of a tool called Gruff.
00:19:13.060 - Jans Aasman But you see, you have a patient, a thing of type person that's an outpatient encounter. So this is an event. So this is the core entity. This is an event type outpatient encounter that happened at this particular time. This event had the effect of patient diagnosis, which was allergic to peanuts is ICD nine ICD 10 code, which is then mapped to an object that matched to one of the 180 terminology systems. So everything to the right here is terminology where you see that allergy to peanuts, perhaps to SNOMED allergic to peanuts, which is the child of allergy to lagoon's, which is a child, a food allergy, et cetera.
00:19:51.170 - Jans Aasman So if I want to find all the people with allergy to peanuts, just go back to the graph allergy to peanuts and find a bunch of people. I can say give me all people with food allergy. Well then it goes back here and then find 469 or ICD 10 codes related to food allergies, and they get way, way, way more people, as you can imagine. Yeah, so to summarize, we have a core entity here, a patient, then we have all the events that happen.
00:20:23.220 - Jans Aasman And then we have the technology system, and this is the same pattern in every other entity event, Knowledge Graph - a core entity, an event graph and then the knowledge base. Yeah. So now let's talk about why this is so cool. Well, to begin with. So you want to do a query, give me all the patients that have gallbladder. calculus after the year 2010. Well, in our Gruff system we can actually visually write queries like, OK, give me a person that has an encounter with the diagnosis that corresponds to a concept that matches gallbladder calculus, where the encounter happened after this particular time, I push a button, it creates automatically the SPARQL query.
00:21:04.770 - Jans Aasman And that's it in SQL. This is part one of three. So this is what you have to do in SQL. It takes you hours, maybe days to write this query and debug. So, again, it becomes.. I can take any one of this audience probably, and and train them in two hours to understand our data model and start doing queries with actual graph that lets you easily create queries. Whereas if I had to take you to the Enterprise Data Warehouse.
00:21:32.040 - Jans Aasman For the SQL, I wouldn't even know where to begin. It would take me weeks to get you going. Yeah. Anyway, so the other thing I talked about is how easy it is to get a 360 overview. So for the people in the audience that can read SPARQL, this just says, well, select everything where the fourth element of every triple is this patient. Identify it and then give me all the triples and I get all the triples.
00:21:55.560 - Jans Aasman Unfortunately, the fellows really didn't like it because now they get a million triples in the Java application, and that makes it still hard to deal with. So now we can also in Python say, OK, give me all..give me a patient, that has this identifier and I get a beautifully formatted JSON object that also has all the data available. Now, an app developer can easily start working with it. And we talked about that it becomes a lot easier and again, it's very important, people always think, oh, to build a Knowledge Graph that's a huge, big, big thing.
00:22:31.510 - Jans Aasman No, it's not. You choose a simple app to begin with, and then you just take the most important events that you need and you start building and you never have to change, the shape of the event stays the same. But if you get another use case, you need a few more events from your database. But you just add events. You never change events, if that makes any sense. Yeah. Then for us, it's important that for every element in our trip, we always can find that where the data came from.
00:23:00.480 - Jans Aasman So 75 percent in an Knowledge Graph is actually provenance data that points back to the database, the table and the column where the data came from and even the data and the procedures that were used to to create this data. And now we have something that I can't talk about today too much. But we can actually also attach a key, key value pairs to every triple in our system. That we can then can use through security filters, so we have by far the most secure system in the world to offer kind of what coracle calls cell level security.
00:23:37.570 - Jans Aasman We can do triple level security so we can write security filters for every single, sorry, four triples, and protect any every triple in a different way, so that when I do queries, I can put also some user attributes on the same, on the user. And like this triple has a security level eight. Well this is a security level to the application layer added. And so this user cannot see these and..I'm going too fast for this one.
00:24:10.090 - Jans Aasman I apologize. And then. One of the things we do, as I said, we have machine learning and then we put the sorts of data back into the graph. So, for example, I could.. for a query like so I have here a database with literally, well, this is the terminology system you have plus some statistical information that we got from the real data. So I can ask, OK, if I am allergic to peanuts, what are the top five other things that I might have?
00:24:43.670 - Jans Aasman And I can render this as a query. And you see that automatically creates a SPARQL query. I get a table with results. Yeah, I can see that if I have peanut allergy and dermatitis due to food taken internally is two and a 10 times higher than normal. So then I can turn this into a visual graph and I could even. Say, are there more statistical relationships between these things here and I can do this and I can use a to look at this and I can start asking for the shortest path between a repair.
00:25:18.400 - Jans Aasman Yeah, and so I can see for every disease, every symptom in the systems, the most related systems. And so that's just because we did machine learning analytics on top of all the data that we have, and then we turn it back into the graph. And so now we have a learning system where we can actually help the doctor. Oh, if this person is different, this he also might get this and that. That's a very quick demo and again, I apologize, it went so fast and then the entity event model has one more really important advantage, and that is you can do horizontal scaling through sharding.
00:25:54.490 - Jans Aasman Yeah. Yeah, because an entity event is an entity event model creates entity, even trees that are logically grouped. Because the fourth element is this patient identifier where she can shard for example, on patient ID. Yeah. So we created the system. So what entity events going to start with entity ideas to shard key, and then we federate every shard with non shardable knowledge bases, so 95 percent of our data can be sharded. Five percent is just knowledge about health care, about dept, about doctors, about other things.
00:26:35.430 - Jans Aasman And we put that into not shardable databases. And then we federated shards with these non federated shards. A lot of patents around this now. And so now we have a system where a user can take a sparkle query. We strip off the aggregate parts of the Sparkle query, we sent the same sparkle query to every chart in the system. Yeah, where the charts are federated, which is not as bad. We get the results back then we do our education.
00:27:05.810 - Jans Aasman And so this allows you to deal literally with hundreds of billions of triples. OK, well, enough about that. And then finally, let me talk about the third use case, which is an entity event, Knowledge Graph in an Intelligent Call Center, where the Knowledge Graph serves as the history of every customer we ever tried to sell to. You have a call center, call center sells stuff for other big clients and you sell to ultimately to customers.
00:27:42.120 - Jans Aasman Or you you sell, you try to set up an appointment for your client. Well, so that is the first roll of this Knowledge Graph. And then the other thing is the Knowledge Graph help with real time decision support. So we listen in to the conversations between agents and customers. We use speech technology and language processing and we can detect all kinds of things while we talk. Let me talk about in a second. So we do this for a company called N3, which just acquired by Accenture.
00:28:13.930 - Jans Aasman And this entity works for all the big guys here selling mostly cloud based services. Many other things. Yeah, and then here is the entity entry for the Intelligent Call Center, the pre-built, again, you might remember from before the core entity, which in our case is the customers you tried to sell to.
00:28:33.220 - Jans Aasman And then. These adheres to events. Well, part of the event is that this is a contact person that your call center agents is talking to, and this guy might have first worked for the CPA in Oakland and then later worked for Acme Bread, vice versa. So this is already an event, people working for a company, an event. And here is one of the call center agents talking to this person. And then here are the court events.
00:29:05.100 - Jans Aasman This is called to make phone calls or to send emails or to check on the website. So this is this is where 95 percent of all the events are. And then here we have the knowledge base of the campaign you're doing from Microsoft, all the names and the relationship between clients, the taxonomies that you need for products, et cetera, et cetera. So this is, again, the same kind of system into these events and knowledge basis. Yeah, but to be but this in itself was already billions of triples.
00:29:35.820 - Jans Aasman But actually where the real mystery is, is where all the gold is, is in what actually happens in the email exchanges between customers and agents and the phone calls between customers. So we did a lot of work in the last two or three years to actually apply speech technology and machine learning to just this little part so that we can help call center agents in real time. Yeah, so we want to we want to know where the agent is, the cell cycle that she moved the process forward to get to a cell, yeah.
00:30:10.500 - Jans Aasman Did the person talk about budget authority need and maybe a timeline? Yeah. Should I correct for open or close questions. Maybe the agent ask too many questions and I can put on the screen, ask some open questions. Does the agent talk mostly about product categories or should she should she talk about the products that the customer actually can buy sellable products? And what should the agent do when the customer starts talking about a competitor? So you need to have battle cards in real time so you can help the concept of agents with arguments against your competitor.
00:30:46.080 - Jans Aasman And, well, if you talk to an agent, sorry, to a customer, it's very important that, you know about the industry, the kind of person you're talking and what to use case of the customer. So, again, in real time, we can help with that, etc., etc.. So we have this system. And I kind of spent only a few minutes on it because we're running out of time. But we have the system where we can take speech recognition, we can any kind of documentation and use Apache Tica or we can take plaintext and we put it in our injust engine goes into the Knowledge Graph and it's just plain simple text.
00:31:26.160 - Jans Aasman But we spent a lot of time building taxonomies. For example, this is for a company called Cisco, where we have all kinds of information about the products you try to sell it. We need to be able to recognize the products they talked about or wrote about. And so we take the taxonomy, put it into the graph, and then take the taxonomy in the text, put it into our entity structure. And now we have entities attached to the plain text we have.
00:31:53.640 - Jans Aasman You can do the same thing for sentiment analysis so we can say, oh, this is a happy talk. Was the customer angry? You also want to know the nature of a call, what was the nature of was this an immediate sale or did the customer want to replace his existing system? So we have label services, automated labeling. Are human beings doing the labeling? And then we give it to a text classifier and we even store our text classifiers directly into our Knowledge Graph.
00:32:22.670 - Jans Aasman Yeah. And then we compute statistical correlations between entities in the text that we recognize, because you want to, you can use that to build recommendation engines and then ultimately you can search in this database using semantic search. But I want to keep this short because I want to get to the end. So with this particular Knowledge Graph here, we can apply all kinds of analytical tools to give the managers and three insights we can do at our queries to figure things out.
00:32:54.020 - Jans Aasman And we used the Knowledge Graph to give real time decision support to the agents. So. OK, I went really fast with and I apologize if you couldn't keep up, but there will be a video of this so you can see it in slow motion or the slides will be available. So but here's the point. So you want to try this? We help people do a proof of concept of the entity event model. Yeah. And again, what I said, you don't need a big bang.
00:33:24.890 - Jans Aasman You can just start with the simple use case with the simple model of existing events that you have in your particular industry and build a simple model because you can guarantee that. Doing more complicated use cases only means adding more events, but don't change the shape of your data. Yeah, we've seen that in just one to three months. We can already show you the carbon benefits of the entity, that model and then finally summarizing. So we we we have proven now to several of our biggest customers that we make it way, way easier to understand very, very complex data and make it very easy to do queries of feature extraction and make it easier to get a 360 view of your entities.
00:34:11.200 - Jans Aasman And if you don't believe us, will help you with your first PoC to make an entity model for your data. OK, so that was my talk for today and let's see if there's any questions.
00:34:23.680 - George Anadiotis Well, thank you. Thanks a lot. Very interesting. talk, actually. Case in point, you got a ton of questions. The only issue is that we're so much out of time that we maybe would have time for one question and it wouldn't be fair to choose one. I think we have at least 10. So what we're going to do is we're going to collect all of the questions and then we're going to share with you offline. And then we are going to get back to the people who asked them offline because we have to to wrap up, as we have another talk in a couple of minutes, actually.
00:34:57.700 - George Anadiotis So thanks again. Thank you for your talk. And we'll address all the questions offline.
00:35:04.640 - Jans Aasman So you said you had one question or just one.
00:35:08.200 - George Anadiotis We have we have many of them actually like 12, 15. It wouldn't be possible to to answer them all. So what we're going to do, we have logged all of the questions and we're going to address them to you and get back to the people who asked them offline. All right.
00:35:23.200 - George Anadiotis OK, OK. So that's it. Thank you very much. You can see the link for the next stop coming up in the chat. We're closing this one and see you in a bit. Thank you.
00:35:36.830 - George Anadiotis Bye bye.