 Hello, and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager for DataVersity. We would like to thank you for joining this DataVersity webinar, Knowledge Graphs versus Property Graph, sponsored today by CHOP Quadrant. Just a couple of points to get us started. Due to 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 in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVersity. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom right hand corner of your screen for that feature. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to our speaker for today, Irene Polakoff. Irene has more than two decades of experience in software development, management, consulting, and strategic planning. Since co-founding CHOP Quadrant in 2001, Irene has been involved in more than a dozen projects in government and commercial sectors. She has written strategy papers, trained customers on the use of the semantic web standards, developed ontology models, designed solution architectures, and defined deployment process and guidance. And with that, I will give the floor to Irene to get today's webinar started. Hello and welcome. Thank you, Shannon. And I should be sharing my screen, so you should be seeing slides. So as I get started, first let me say a few words about CHOP Quadrant as a company we founded back in 2001, which is the same year that semantic standards, semantic web standards first became available. And the technology that we work with has been progressively over the years known as semantic web technology, then linked data technology, and then more recently, knowledge graph technology, because as graphs became better known and more of a household name, it's fundamentally a graph technology for the web. From the beginning, CHOP Quadrant's mission was to help organizations bring applications, build applications that make enterprise information meaningful and more recently, since about 2016, we have been working on enterprise data governance applications connecting enterprise information. So our today's agenda is on this slide and it has a picture of me a few years ago as many of us, I think that hopefully I haven't changed that much, at least I'd like to think that way. And I'm a CEO and co-founder of CHOP Quadrant and today we will start with a brief overview of two graph data models and technologies, property graphs and knowledge graphs. We discussed differences in terminologies and capabilities for these two different technologies, strengths and limitation of either. And then we talk about why knowledge graphs provide a strong foundation for data-centric enterprise applications and in doing that we'll talk a bit about what it means to move to data-centric applications. I'll do a couple of short demos to demonstrate how graphs look like and work and hopefully we'll take a bit of time for, we'll have a bit of time left for Q&A. All right, with that, let's get started and I have a few definitions here of a knowledge graph as a term and they come from different sources and here's of course the source of all truths also known as Wikipedia and there's some differences in those definitions but also quite a bit of similarity, you know, essentially this is knowledge graphs provide a way to organize data about real-world objects, real-world entities in the graph and together with this data there's also information about the data model. So here you could see it talks about possible classes and relationships in the schema and in Wikipedia we talk about, you know, semantics of the real-world objects and this definition in the middle talks about ontology, which is again the model a term used to describe the model behind the data. We at TUF Quarter, having worked with this technology for quite some time, also have our definition of what are the knowledge graphs. So fundamentally we believe that knowledge graphs represent information about some domain of knowledge and represent this with active models, models that can be consulted at runtime. This information is stored in a form of a graph. What it means is that there are nodes and links or connections between nodes as opposed to, for example, tables with rows and columns as you would have in a spreadsheet or in a relational database. Importantly, knowledge graphs can contain both the actual data effects as well as the information model behind those parts. All as part of a graph and this model can drive interesting behavior, including rules, inferencing and so on. Another important fact is that knowledge graphs are based on open standards from top to bottom, so from the data to the models of the data and rules. The reason that we believe this is important is because even within a single enterprise you have a variety of information and you will not be able to put all of that in one knowledge graph. So interoperability, connectivity, etc. are very important for the graphs and the structure of the graphs makes that possible, but you also need the open standards in order to make this information shareable, connectable, and so on. So ability for the knowledge graph to grow and evolve over time is important. So let's take a look at how a knowledge graph may look like. And this is kind of using knowledge graph recipes. We also sometimes talk about RDF knowledge graphs and RDF is the data model or standard behind the knowledge graphs. So it stands for resource description framework. So here on the left we see a bit of a model or ontology that talks about organizations that have some vehicles, design models of the vehicles, and so on. So that's a model or schema with classes, properties, etc. And then on the right we have a little bit of a data that uses this model. So here we see BMW as an organization and it has some car models designed in some year and you could imagine additional data that maybe has to do with a number of those models. So there are popularity prices and so on. So when we combine this together, you know, this is kind of a blueprint and this is the actual data and combining it together, we have our knowledge graph. So ontology plus instance data, that's a recipe for a knowledge graph. Now, having talked about knowledge graphs a bit and you know pointing out that they are based on the standards there. So there are four, there is a standard data model behind RDF knowledge graphs. With respect to property graphs, I will describe them and as I describe them, I want to make a caveat that there is really no de facto, de jure standard property graph data model. There are quite a number of different implementations that they are all calling their implementations property graphs or labeled property graphs. There's lots of similarity in those implementations, but there's also some differences depending on a particular vendor product. What I will talk about today will tend to be in facts that are similar, identical across different implementations. So that the true for different implementations, I will not go into details that may be different, but it is by and large. And in general, in property graph data model, we have three elements. There are nodes, which are entities, nodes in a graph. There are links between them also called edges and this relationship between nodes. And then there are properties. Properties are key value pairs that kind of hang off either nodes or edges. So let's take a look at it by example. And in this example, I'm going to use some data from the entertainment industry. So you see two nodes here. One has ID 123. Another one has ID 125. You also have a relationship between them. And depicted here in yellow, you have properties that hanging off those nodes and also a property that's kind of hanging off the link or an edge. So 123 stands for Tom Hanks. And you see first name, last name, you're born as a property. And 125 is a movie. You see the name of the movie and it was released. So these are also properties. So these are literal key value pairs, such as integers, strings and so on. And then you see here that the relationship between them has a type. In some implementation, this may not be called a type, may have another word, but quite often it's called a type. And it also has an idea of its own. And there is a bit of information hanging off that as a property. So we see that Tom Hanks acting in the movie The Post had a role playing Ben Bradley. And then we also see blue rectangles that contain labels. So the full name of a property graph data model is labeled property graph. And labels are essentially types of those nodes. They are stored similarly to how these properties are stored, but because these are strings associating essentially a type with each node. So we see that Tom is a person, director and an actor. But they are, they're special kind of properties. And that's why they're shown in the blue here. So let's expand our graph. We see another person. This is a person and an actor, Sarah Paulson. And she also acted in this movie. So another act, another link of a type acted in, but different ID. And she played Tony Bradley. And we keep on extending the graph. So we now see that Tom is a director. He directed a TV series. And then we see more connections from the post to the location that this movie was filmed in. And more information about those locations. So now let's take a look at this same information of how would it look like in an RDF knowledge graph. As I move there, take a note of these IDs. So you see in the American IDs, they get assigned by your property graph system, internal IDs, similarly to how relational database may assign some IDs. So I'm going to show exactly the same information captured in an RDF knowledge graph. So here we see information about Tom. And here's a note representing him. And here is his birth date, his given name, family name. And then we see two links to types. And we see that he is an actor. So this note is of type actor and a type director. I don't have a type person here. And later on, it will become clear why not. And then he acted in a movie, the post. So a couple of things to point here. One has to do with IDs. So you see the ID has kind of two parts. One is a part before the column and another one a part after the column. So the part before the column is actually is a prefix that stands for the namespace. So you see if we wanted to expand it as a full ID will have the entire URI. So Vicky data stands for this namespace. And then you have a local part of the ID at the end. How exactly IDs are assigned, you as a user of the knowledge graph systems have some control over. You could select different namespaces. And you also have some control over how the local part is generated. And the reason it's important is because as I mentioned before, you know, there may be multiple knowledge graphs that could be connected together. I mean, specifically Vicky data, for example, is a knowledge graph that contains all the information in the Wikipedia in this kind of structured, credible knowledge graph format. So in this knowledge graph, thumb hangs actually exist, exist as a node. And we could connect to the information in this external graph. And it could be useful to reuse the ID that is being used in Vicky data for a variety of purposes, you know, as a reference data or to assist in merging and connecting between different graphs and so on. So we could do that. Or we could also meet our own IDs using different strategies. So that's one difference. Let's keep expanding our graph. And we see here information about Sarah Paulson, her name, Shakit in this movie, we see a league of their own, which is TV series. And then we see information about locations. So another thing that you may already noticed is that information is stored in a very regular way. Everything is a node in a graph. So the node representing thumb hangs is a node. The node with his name or his birth date is a node. Instead of being a different separate structure, data structure, it's just a node and everything is connected via relationships as a link, so as links to this highly canonical structure. And then types also, all of them are nodes in a graph. It's a very canonical representation. And that's, we're going to have this rolling slide of differences in similarities as we move along. So we've talked about IDs in property graphs being internal to a specific graph database with no control for the user. And in the knowledge graph IDs are globally unique URIs. They can be under user control to support combining different graphs. And then canonical structure. In one case, you have nodes, relationships, properties, very different things structurally. In another thing, in another case, everything stored as a graph with nodes and links connecting them. So let's talk about schema as part of the knowledge graph. And here I have highlighted some of the nodes in red because they are special. They are types or classes. They also have the identity, the same type of identity. So they have URIs, so IDs, just like, you know, Tom and the poster movie have identity. They're part of the graph. We could store information about them, about those types or classes. And in fact, we do. So here is, you could see why I did not have, why I did not say in my original representation that Tom is also a person and not just an actor and a director. This is because I am putting this information on a class itself. I'm saying that the actor is subclass of a person and director is subclass of the person. And because I say that, I don't have to say that for every actor, for every director, it's captured in a schema. And I could connect movie and series because both of them are subclasses of this class-created work. I could say more about the city being ultimately a place and the subclass of administrative area. I could capture other information, including like display names or labels. So this is for the edge, for the relationship connecting called actor team. So I could have a human readable label for it. And I could do more. I could actually capture very rich schemas as part of the knowledge graph. So we could see a small example here where this slide shows the kind of properties that a class-created work is described with. So we could see that there can be a release property for instances of type-created work. And this release property, its type would be a date. And it cannot be more than one, at least in my model, in my anthology, there cannot be more than one release date for the creative work. And also, you know, this is how I am defining here. It has to be larger than 1900 because in my, in the kind of data that I am capturing, I'm talking about movies and TV series, so you cannot have something from 1700s. So this is just one example of how information about properties, relationships and literal values can be described in a very rich way. The same way even richer definitions can be captured, including includes. And this is important because increasingly this type of models called anthologies as well as controlled vocabularies of reference data are being developed in different in different industries and being reused, which facilitates interoperability. So here's a few examples. In my example, I'm actually using schema.org. And schema.org is anthology developed jointly by Google and a few other being a few other search engines. And this is to facilitate annotations of the information on the website. So it could be presented structurally and drive smarter searches. So I'm using properties and classes, class definitions from this schema.org. In my example, as well as my own, you could combine your own and you could extend standard anthologies. There is lots of domain specific anthologies. FIBA is for is a financial industry business anthology. There is quite a number of anthologies in life sciences and medical domain. So mesh is one of them, medical subject, headings, nomads is another one. QDT is a standard model for quantities, units and dimensions. So all of this is quite useful because you could use those standard anthologies to support interoperability and the emerging cognitive enterprise. So another difference is how schemas are treated in property graphs versus RDF knowledge graphs. When you implement the property graph, you will develop some kind of a data model because you need to know what data you will be capturing and how it's going to look like. You'll need it in order to write your applications, write your queries, etc. And there are some methodologies for data modeling for property graphs. You do your data model kind of separate from your graph sort of off band, maybe using a piece of paper, maybe using some white boarding exercises, maybe using PowerPoint or another tool. And then once you develop the model, then you organize the data according to this model. But the model stays in another artifact. It's never actually part of the graph. And if you need to make a change, you can go back to your paper based or some other based representation. With knowledge graphs, it's more integrated because you actually model within the graph and then data is structured according to this model. So it's more seamless in that way, your model leaves in the graph. And this is probably a good place for me to stop for a second and show a bit of a demo that can actually bring this concept to life. So let me switch. And I am now in a tool. It's our product called Tabred Edge. And it's a product for managing data as knowledge graphs, creating knowledge graph. And I have a little example here that actually has a data about Tom and Sarah, according to this, you know, entertainment ontology. So you see that Sarah has acted in a post the movie in this role, Tony Bradley. And you see her name and gender and given name, et cetera. And if I wanted to go to Tom, I also have a similar kind of information. And I could keep expanding the graph and see more and more information. So there's some information about white planes and that the movie post was filmed in, some information about population, and so on. So it is a graph. So it's interesting to look at it as a graph. And we have feature here that allows us to do this. So let me make it a bit larger. So you see Tom and the fact that he's acted in the post. And we could expand and also see that Sarah has acted in this movie. And here we're going from the movie, we're starting from the data, we're starting to go into the model. So we see that a type movie and that's a class. And if we wanted to expand a little bit more, so let me go and just pick what I'm going to use. Sorry. The screen is real estate is a little bit. So you've got the type movie and we could keep expanding more. And we see that it's subclass administrative area. And it's a class movie. And if we wanted to see more of a model in terms of how properties are defined, there's quite a bit of richness here. And we could see all this properties of the movie also as part of the graph. So seamlessly going from data to the actual definition of the of the model. And as I go back to, as I go back to my data, there are a couple of things that couple of more things that I want to show that I will talk about in the slide shortly. But there is also a standard serialization of the way to represent this data as a graph. So let me add information to this link and say that Tom has played a role of Ben Bradley in this movie and safe changes. And then we'll take a look and see how it looks like in the standard serialization. So you see this ID of the notes that I've talked about. You see the date of birth date, family date. You see this is how additional information is hanged on a note itself called, you know, they're all Ben Bradley. And if we wanted to look at the prefixes, so this is how prefixes are defined with Vicky date and some other prefixes we use in our models. So let's take a look a little bit more at this serialization. We see that their family name and a given name. And if we look at the information in the form and the information that would be available to us in the query if we were to access this data, we see that there's also a full name, but it's not actually captured in the data. So where does it come from? It's actually comes from inference rules. I've mentioned inference a few times before. And when you look at this information, there is a number of rules that have been defined here that take available data and ensure additional data. So this is one of the rules that is quite simple. Basically, it takes a given name and a family name and concatenate it to create a full name. And there are some, you know, some richer rules here as well. But this is what's managed by the Knowledge Graph based on the models. And even though the full name doesn't exist, it's still presented to you and is available to you as if it did exist. So let's go back to our presentation. And so I just showed how to add information to this octet in node. And you may have noticed that in the previous slides, although I represented in the Knowledge Graph everything that was in the property graph, I did not represent one thing, which is this information about the node, you know, what role some octet in this movie. And this is because there is another difference between property graphs and an idea of Knowledge Graph. In a property graph, each link, each edge has its own identity. If you remember, we had this octet in this ID 10, and another octet in this ID 14. In RDF Knowledge Graph, it's actually the same octet in. So how do we add information to it if the link is the same, whether it goes from Sarah or whether it goes from Tom? There is an approach for doing it. There is a formal model for doing it called RDF Reification, where basically you take this triple fact, which is Tom octet in the movie, the post, and you reify it by creating another node, this example 126 node, and you say that it reifies this triple, this fact, because you say that the subject of this node is Tom, the object of this node is a movie, and then the predicate is this octet in link. And then once you've done this, you could hang additional information on it, such as that he played a role of Ben Bradley. So this sounds to some extent complex, but as you saw in this demo that we just did, it doesn't have to be complex at all. I just entered Ben Bradley and tools take care of it, and how exactly it is stored. It's all managed by the tools. So the important part that there is a standard way of doing this. And there is a short format for it called RDF Star Reification. That's what we use in our product, and a longer interchange format as well. And this type, this node is of type RDF statement, so that's how formally it's defined in the models. So this brings us to this additional difference is in a property graph, each relationship is uniquely identified already, so this each combination of a node, link node is uniquely identified by this relationship. And you could annotate these relationships with additional facts. You can't annotate properties with additional facts because they just hang off of the nodes. They themselves don't have identity and there is no way to give them identity. In RDF, all the properties are used. So you can simply use a property to identify this node, link node, triple, but there is a way to give it an identity through this verification method. And once you do that, you could annotate any connection with additional facts, whether it's a connection between Tom and movie or whether it's a connection between Tom and his birth date, you use the same approach for it. So one of the important value propositions for graphs in general is their availability. With that, I'd like to kind of talk about how you could evolve property graphs and how you could evolve knowledge graphs to test this stress test, this availability quality. So let's say you have a property graph and we've got white planes, it's a CT, white planes has population. But of course, when you look at white planes, you recognize that it may have different populations. And it's not that it has this two different or five different populations at the same time, it has these different populations at different points in time. So how can we say that this population is 2018, this population is 2010 or whatever that may be? In order to do this, you can't really do it for the property in a property graph. So in order to do that, you need to turn the property into a relationship. You need to change your graph structure. And here's one way of how you may change the graph structure. So you create additional nodes, you say that there are populations, and then you hang the size and year property from them as property. Or you could hang a year of this edge and there's possibly some other structures for doing this. The important point is that you can't really, you know, you can't keep this structure. You have to change it to something like this. Once you change the structure, this means that the queries that you've created and the applications that you have developed that relied on the structures would need to be modified. Now, how do we do this with RDS? Well, using the method that I just showed, so you've got two separate nodes, each of them representing population, you can now create another node that will represent this fact. And then you could add a year value to it. The important point here is that we haven't, we have evolved our graph. We have added more to the graph. It's grown larger, but we haven't changed anything of what was already before. So there's still a link between, between white planes and any population. We've just added something to the link. So what that means is that if you have developed any queries, rules, applications that depend on this information being captured in the graph, they, they could be as they are. You could of course take advantage of additional information, but at least you have not broken anything. Now, let's consider another change case. So we said that Ben Bradley is a role that Tom has played in this movie. And we're just using a string, a textual value Ben Bradley. But we may want to actually talk about a specific resource or a node Ben Bradley, because Ben Bradley is a real person. There's some information about this person. So when we want to say that Tom has played the role of that person as opposed to just having a string. So again, if you're using a property graph, you have to change your graph structure. You can no longer have this information hanging off this, of this relationship, you have to create another node, you know, saying with the type movie, portrayed, movie character or portrayed in a movie or something like this, that would be a person. And then you could, you could link to it. So again, there is a change in the graph structure. In case of the knowledge graph, we use exactly the same approach. So we had Ben Bradley as a string, we could, we could simply change it to be a node that is not a string, but rather an ID. And that could seamlessly connect us to, let's say, entry in a Viki data graph that has additional information about Ben Bradley. So from the evolvability perspective, there are some differences here where this property graph changes are more likely require restructuring of the graph and changes, possible changes, likely changes to impacted queries and so on. And RZF knowledge graphs in that sense are more malleable, you really evolve and extend them and you could preserve more from your logic and application code, they kind of better protect it as you evolve the graph, you also don't really need to restructure your data, you just add to your data. And a few other differences that I showed in a demo, well, actually, one difference has to do with queries, I didn't really show it in a demo, but I sort of alluded here by talking about queries. And of course, if you have data in a graph, you want to use it. If you want to use it, you need some approach to creating this data. There is a standard query language for the knowledge graph that is supported by all systems that implement RZF knowledge graphs. There is no de jure standard for property graph query languages. There are some queries languages such as Cypher, which came from Neo4j that is implemented by more than one property graph vendor, but not necessarily by all. And they also have some differences in implementation since it's not really a standard. There's also some proprietary languages, query languages that each vendor provides. Increasingly, what we notice in industry, there is a move to support GraphQL, which is a query language from originally from Facebook, but it's became de facto industry standard. And you could think about GraphQL as a possible common denominator in the space because vendors in the property graph space and in knowledge graph space support GraphQL. It's a pretty rich topic, the whole topic of query probably could be a topic of webinar of its own. So if you have interest in it, let us know and we could talk about it more outside of the webinar. Also, we have a white paper that has been written on this property graph versus knowledge graph comparisons and there is more about query languages in a white paper. And the thing that I did show in the demo is serialization. So there is a standard serialization for this, the way to take graph in the knowledge graph system and export it in a textual format or the way to take text and load it into the knowledge graph system. There are standard serialization formats, you've seen one in a demo and here you could see how it's represented in the text. So this would be a subject node, this is an edge or a predicate, this is an object node, people parts like this. And here is another one. So again, we're talking about this subject node now acted in edge and acted in this movie and this is how this RTF verification is supported by hanging more information on specifically on this edge. So differences in serialization property graphs have some proprietary serialization formats and maybe some programs that you have to write. And then the standard serialization in this RTF knowledge box space. Another difference is based on this unique ideas and how composing of the graphs is supported. So knowledge graphs are self-organizing, they can be composed. So we can have a graph like this that talks about some data element in some data sets stored in some system. We could talk about some system running on some server in some data center and then something about location of this data center. Through this unique identifiers, we could bring this information together and you get connections between them. So because the URI or ID of this node was the same in both graphs. And then you could also build connections between nodes in different graphs. And then you could infer additional connections based on location. And maybe if you have some GDPR type of information about personally identifiable information in some location, you could do further inferencing based on it to say what can be stored someplace and what cannot be stored. So this consistent identifiers with nodes and links gives us ability to merge graphs together and infer additional facts. So that's our connectivity difference. The fact that you could partition graphs, you could distribute them and then you have the form of framework for merging and connecting them. Now that I've talked about these differences in similarity, let me talk about some use cases. Why would you want to use graphs and knowledge graphs specifically? So there's quite a number of use cases. One important use case has to do with this move that is currently underway in enterprises from data-centric versus application, from application-centric versus data-centric architecture. So moving from application-centric to being data-centric. And I'm not going to read this busy slide, you'll get the slide, but you see the main differences focused on data being self-describing, with data-sharing built-in, data being active because the semantics of it is in the data. Let's take a look at an example of why self-describing data is important. So you see a bit of a data here. It's an open data about road safety and vehicles, etc. So if you look at it, it's an interesting data, but at least to me, it's not particularly meaningful. There is some metadata, but I don't really understand what this means of 7F8, etc. So data, when you try to share it, when you try to use it, it's only as good as its metadata. If you can't understand it, you can't really use it. Here's another example of the data. And as a person, it's more understandable to me because at least there's meaningful names that I as a person can interpret. But if we want applications to use and interpret this data, we really need to have much more structure and much more semantics and richness. So we need to know whether something is required, what format it takes, what rules may be associated, visit, etc. So with respect to data and being able to share data, here are some key facts. So metadata is not readily available. You can't really understand the data. If it's separate from data, then applications can access it. And it's important for metadata to be together with data because if it's someplace different, you have kind of silenced, fragmented systems where metadata gets stale and outdated, it's also important for this metadata to be captured in a standard way because that's key to sharing. And that brings me to another, you know, we very short demo that I want to do. So far I showed an edge, kind of a neutral data about some entertainment, some hangs, movies, etc. But what Tabred is mainly for is a composition of knowledge graph to support adaptive data governance. It comes with a lot of pre-built asset types that talk about databases, data sources, applications, forms, reports, etc. And they all come together to form this knowledge graph. And I'm going to show just a very small example of it. And so this is information from some medical enterprise. And you see, for example, information of the medical enterprise. And you see that I have some catalogs of systems. I have some catalogs, technical assets, some catalogs of forms, reports, I have some data sources that I used here. So if we take a look at here, I've got some forms and reports. And if we look at patient discharge form, you see some information about it, more documentation, the individual items that are data elements that compose this form, exchanges that form participates in. And it's connected throughout enterprise with different applications and systems. And I could take a look at it in this kind of a reach of view where you see this is how patient discharge form different systems that contribute and different processes that contribute to creating this information, and also different enterprise stakeholders in the role that that contributed. And these links are clickable, you could get more details with the launch, logical lineage, application kind of linkage, data lineage, etc. But so this was a very short demo because we've been getting close to a lot of time. And I do want to leave some time for questions. So I'm just going to leave this slide here. It shows how models support data capture. So in our customers, we have a number of customers that have started by using property graphs because property graphs have been known to be easy to get started with. But they also ran into some bad ends in some challenges. And you could see them here. And essentially, I've covered them when I covered differences have to do with not being able to capture schema with not being able to use inference, you know, lack of connectivity, etc. So with that, we have some customers that've been moving from the property graphs implementation to knowledge graph. And if you find yourself in this position, there is a well defined and structured approach to transitioning. So you could get your data out of the property graph, as is some tools such as Neo4j will even generate one of the standard representation for you or program can be written. You're not going to get a model out because the property graphs don't capture the model. But a template edge, for example, will introspect your data and will generate a model for you. And that may that model may need to need to have some tweaks and refinements to take advantage of capabilities of the knowledge graph. So some iterations will be needed. But that's a good starting point. And then with respect of migrating application code and queries, that would be the next step. And as I mentioned, GraphQL is often a common denominator. So if you're already using GraphQL, then you may be able to reuse at least some of your queries. So in summary, some key takeaway points, so graphs are increasingly are important to enterprises for their flexibility or ability to support data sharing. They're an excellent choice for a number of applications, including this transition to data-centric enterprise representing data. There are two property graphs, two knowledge, two graph models, property graphs and knowledge or RDF graphs. Traditionally, property graphs have had a pretty mature implementations, for example, Neo4j, which pioneered property graph space. In the past, knowledge graphs were considered to be more academic. But recently, I mean, recently probably within the last five to 10 years, lots of products and tools have been developed. And there is now mature implementation and support for knowledge graphs. They support production systems running for quite a number of years. And this technology makes it just as easy to use knowledge graph as property graphs. And as I described, it's possible to move from your property graph implementation kind of to graduate into a knowledge graph in some logical steps. So with that, I switch it to Shannon and see what questions we have. I mean, thank you so much for this great presentation. We do have a lot of questions coming in here. I just answered the most commonly asked questions. Just a reminder, I will send a follow-up email to all registrants by end of day Friday for this webinar with links to the slides and links to the recording. So diving in here, Irene, what is the difference between a knowledge graph and a conceptual data model? Well, a conceptual data model can be implemented as a knowledge graph. It's kind of an idea. A knowledge graph is a set of standards supported by technology. So it's an actual implementation. But you could take your conceptual data model, express it as a mentality within a knowledge graph, and start patulating it with data. So if you have conceptual model about, you know, people, movies, actors, et cetera, put it in the knowledge graph as is. There is a way to create classes, create properties. I didn't show that, but we have quite a number of demos around it. You create it exactly the same way you create the data. So you have your model living in the graph, and then immediately you have ability to, you know, patulate it with data, start entering data, start loading data, and so on. And Irene, this question came in earlier, but I think you covered a little bit of it, but isn't a property graph a type of graph database and a knowledge graph is an application of graph database? In other words, can't a property graph we use to create knowledge graph? Wouldn't it be more accurate to compare RDF and property graph? Yeah, so let me, I've described that there are two different data models. So there is a property graph data model with nodes and then edges and then properties hanging off the nodes. And then there is RDF data model where there are resources connected by links where everything is a node. So when you talk about properties in the RDF world, it's relationships between the resources that have IDs as well as the relationship between the resource and the literal, etc. And there is a way to actually put your data model, your ontology into this graph. So there is a standard, you know, data model and built on that standard data model. There is standard knowledge representation languages, such as shock or shape and constraint language, which we use for expressing models, for example. And I was a leader of the working group, chair of the working group at WCC World Wide Web Consortium that developed Shackle about three years ago. And now it's supported by all major RDF database vendors and, you know, vendors like ourselves for the photobraid edge. So we, referring to it as a knowledge graph, because you could actually store the knowledge, the model, the rules in the graph itself. While in a property graph, you can't do that. You have to keep it separate, so you could only have your data. And the semantics of the data are in programs, in some requirements documents, in people's heads. And as you saw the definitions of the knowledge graph that I started with, they all talk about semantics, ontologies, schemas. So if you follow that type of a definition of the knowledge graph, then you can't really say that the property graph can be a true knowledge graph. You could of course, you know, come up with some different definition of a knowledge graph. Thank you. I think we have time to slip in. One more question here. Is building inference roles the same as creating nodes and edges? For example, links established so the inference can be made? In some ways it is. So in which way is it the same? So it is the same in a way that you also put those rules in a graph. So if I, you know, if I had time, if someone is interested, I could show, I would be able to show how a rule looks like in a graph. So this resource of type rule, there is a language for creating it. It is stored in a graph. So you could actually query your rules if you wanted to. You could reason not only using rules, but you could kind of meta, meta, you could reason over your rule based in terms of what kind of tools you have. So in that sense, it is, it is the same, but you do need a way to represent your knowledge. And I've already mentioned Chaco. So Chaco offers you a way to say, so I have people and people have names and names must be strings and people have data burst based on the burst must be integer and there must be only one day the burst. And people could have parents and those parents are also people. So you could, you could have information, you could, the language that gives you a way to say things like that. But it's also a language that gives you a way to say rules. For example, if both parents have blue eyes, then a child will also have blue eyes. So it gives you a language for saying all of this and capturing all that richness in, in the knowledge. Well, Irene, that does bring us to the top of the hour here. I will send over so all the remaining questions that we've had have been some great questions from the attendees today. And thanks for all being so engaged in everything we do. It's been such a great presentation. And again, just a reminder, I will send a follow up email by end of day Friday to everybody with links to the slides and links to the recording as well. Thanks, Irene. And thanks to top quadrant for sponsoring today's webinar. Appreciate it. Thank you, Shannon. Thanks all. Have a great day and stay safe out there.