 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining the DataVercity Graph Modeling in Four Dimensions, Outline Differences, Artists and Chip Agility, a celebration and preview of Thomas Friesendahl's new online training available in the DataVercity Training Center. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. 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 middle of your screen for that feature. For questions, we will be collecting them via 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 DataVercity. And if you'd like to continue the conversations after the webinar, you can go to DataVercityCommunity at community.datavercity.net. 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 you our speaker for today, Thomas Friesendahl. Thomas, a graph data architect and visual data modeler, is an experienced database consultant with more than 30 years on the IT vendor side and has an end as an independent consultant. He has worked with databases and data modeling since the late 70s and since 1995, primarily on data warehouse projects. He has the strong urge to visualize everything as graph even data models. He excels in the art of turning data into information and knowledge. His approach to information-driven analysis and design is new Nordic, the sense that it represents the traditional Nordic values such as superior quality, functionality, reliability, and innovation by new ways of communicating the structure and meaning of the business context as graphs. Thomas is an active writer and speaker and in fact has a popular blog series on DataVercity.net. He lives in Copenhagen, Denmark, and we're so glad to have him here in this late evening for him. Thomas, hello and welcome. Thank you, Shannon. You introduced me greatly. I really have nothing more to add to that unless you want my complete biography. But one thing that sort of goes through everything I do is that I work in the interface between business and technology. And my take is that computing is a human activity more than anything else. And we should handle it based on the premises of being humans. And that's why graph data modeling is a really attractive opportunity for most people these days. And I hope over the next 45 minutes or so to tell you basically the most important reasons why graph is really interesting to most people these days. So I called it graph data modeling in four dimensions. And the four dimensions are first outline. Outline of course also describes what the graph area is about. But also I'll try to sort of show you the shape of what graph solutions kind of look like. Then we have the differences dimension, which is a question that many people ask obviously, how is graph different and where is it the same? And what should we watch out for if we come from a classic data modeling background? Then in data modeling, we are proud artisans. Most of us, all of us I think, we know what good artisanship is. We know what a good data model is. And we want to be able to contribute that value, those values to the kinds of solutions that people are using. And so artisanship, is it still relevant or what? That's what that dimension is all about. And the last one is agility. You know, these times we are living in are sort of trying to balance between compliance on one side and agility on the other side. And that is a very interesting discussion. And one of the reasons for graph to be very successful is that you can actually apply graph solutions in very agile styles. And we'll cover that in the last quarter of the presentation. So, the first dimension, the outline of graph data modeling, basically it's the what question and the why question. What, because we need to spend some time looking at the what, because unfortunately the what is a little bit muddy. It's not a clear picture. It reminds me really of the database in the 70s and the 80s, still the same kind of thing, not a clear picture, but trends are emerging. And we have some standards coming out which will change this. And after that, we'll move into the why question. Why is this attractive? So let's start off with the what side of the house. First of all, there are two major parts of the graph area. One is called property graph. The other one is called semantics, really. It's the first one of these two appear was actually the semantics movement. It came out of the W3C, the work by the web consultant. And it actually appears around year 2000 with the RDF standard for how to describe websites on the internet as a result of the intention of that project. So it became quickly a question of linked information, linked data on internet sites and the internet itself. And for doing that linkage, you need to describe semantics. Semantics is another way of saying structures that describe content. So there you have it, the semantics and structures and data models are sort of the same thing, really. Now, to the right hand, what you see here is a specific example of an RDF business standard, which is the financial industry business ontology, which is a industry-wide, well, I call it data model, knowledge management, people call it ontologies. But when we were talking about this, more or less the same thing. It's not tables and columns kind of data model, but it's a conceptual model on concept model and it involves classes and inheritance and things like that. Now, the second player on the field is a project graph shown to the left. One of the most popularized examples of a use case of project graph was the famous Panama Papers leak a couple of years ago. Somebody got presented the files containing information, confidential information about investment activities focused on Panama, as you may recall. Now, that particular dataset was rather large and it was what we call heavily connected data. I'll show you an example later on where we can see how connected it really is because one of the big differences between classic data models and project graphs is that don't shy away from relationships. Do not try to avoid all those links. You need those links. They are real, they describe reality. So heavily connected data is a very good use case for project graph. Unfortunately, if we move on here, if we look at it from the database engine perspective, what is a graph database management system? And the picture is really, well, a little bit difficult to understand. I don't know if you know the site called DB engines. It's a very good site that I use from time to time. They collect ranking information of all kinds of database management systems. And one of the categories is graph DBMS. And here you have a little snippet from that site. And you can see, for instance, is the Microsoft Azure Cosmos DB database is not only a graph database, which it is, but it's also a document store, the key value store, and the white column store. So we got a mix of pure graph database products. We have got some document products, which also do some kind of graph support. And we have the same products, also handling key value and the white column architectures. Doesn't make it easy for us to look and compare, right? But let's go one level down into RDF, the semantics discussion. This is a favorite example of mine. What you see here is expressible in RDF. RDF itself is an XML-based language. So what you do is you describe the structure like this in XML using RDF syntax. And what you see here is actually you got some persons, Woody Allen, for example, and you've got some movies to roam with love, midnight in Paris, and anything else, and watch up Tiger Lee and so on. And you've got some roles that persons can play like screenplay writer, actor, producer. You've got the movies over there. So if you look at this little picture, what you will realize is that you can read this structure here as little sentences. Woody Allen wrote to roam with love. He also wrote midnight in Paris. Midnight in Paris is a movie. So is anything else? If you move down a little bit. And Woody Allen, as a matter of fact, also acted in anything else. So these little sentences, subject, predicate, object is the semantics here. So that's called tribbles. And RDF databases are frequently called the tribbles stores. But when we move on to project graph, you'll see that the same, really the same structure is found in that environment also. Now, over the last 20 years, RDF has developed into a very well-developed metadata description facility, much like UML, for example, where you can define classes and inheritance and what have you, associations and so forth. And it is used for complex ontologies as a term is. Which is business concept models, based on advanced structural capabilities like classes and some classes and so on. So that's a rather popular environment and it's grown in popularity in the last couple of years. And we'll come back to that. Now, what is the property graph side of the house? Well, there are two schools of property graph one is driven by the Apache TinkerPop projects using a database language called Gremlin. That's supported by a number of products like Amazon Neptune, Azure, Cosmos DB, DataStacks, Tengish Graph, Cypher for Gremlin, OrientDB, StarDoc and there are very many other companies. Cypher is the primary language in my perspective and project graph that was developed originally by Neo4j but is today an open source project under the name OpenCypher. And as you can see in the list to the right, there are a number of vendors supporting OpenCypher, not least Neo4j obviously, actually invented the thing, but also big companies like SAP HANA and other people. Interesting enough is that there are also SQL kinds of property graphs. Oracle, PTQL, SQL Server 2017 Graph and Tiger Graph G SQL have been around for some years and that last year, the ISO SQL standardization committee actually proposed the property graph extensions as a project. That project is now being developed so that you will be able to within SQL define property graph structures on top of existing SQL tables and do property graph style here it is on top of SQL databases. Now that's something, isn't it? So what is the property graph idea? Well, actually if you look to the left, you see the property graph concepts we have a property graph. It contains notes, it contains relationships. Relationships organize notes and relationships may have properties and notes may have properties. So already here you see that the concept map which is really what we are looking at here is a graph itself. And you also immediately notice that property graphs are somewhat different from SQL databases because you can place properties on relationships that is not doable in SQL. What you have to do in SQL is to introduce a bridge table in the middle. But otherwise it looks somewhat like a structure that you get out of an entity as a real relationship model. So for the property graph meta model to the right, we have some business objects types which can use relationships to a target and origins to relate to each other and names and they have properties as do relationships also. And the properties are sort of embedded within site a node and properties can have some additional properties like name, they can be identities they can be uniqueness criteria and they can have data types. So that's a pretty simple model. Some of you have heard a lot about the knowledge graphs these last year or two. What is knowledge graphs then? It is actually in my opinion a very fine idea. It can be implemented as well as semantic graph as in property graph. And you can use it sort of as an integration layer on top of silos like enterprise databases, enterprise data warehouses, data lakes and so on. And you can use the knowledge graph which is actually an active graph relating things across those underlying silo systems. You can use it for navigation, you can use it for integration, even integrating streaming data coming in. You can use it for automation of a large, something happens to a stock on the stock market who we have that have those stocks in their portfolios and so on doing that kind of alerting. If you have a strong semantic focus you can do that and not yes. If you have a network focus you can do that in property graph and you can do hybrid solutions. And this is in my opinion sort of a rebirth of the good old idea of operational data stores. So the SQL standard I briefly mentioned here you have some documentation about it. It's an ongoing SQL standardization project. As a matter of fact, I happen to be a member of that committee. It's very interesting. And the work has not been finalized and it does not seem as if there will be a standard this year but hopefully next year but it's a little bit too early to say. This SQL property graph standard will evolve into a standalone graph query language standard as well. So that's interesting. So this concerns the what part. Now the white part is a lot easier to understand. In the graph world, people have this mantra really everything looks like a graph. Let's have a look at a graph. You know graphs are pretty close to what we actually draw on white bones when we want to explain structure and meaning. So here we have a little data model. City is the place location of suppliers. We have the parts which are being supplied by suppliers as supplier parts and with a quantity. So that's a nice little graph model. And so, you know, graph fisters they call themselves they take this very seriously. They say, well, it's just a question of moving this off the whiteboard and into the database. And actually this makes a lot of sense because if you look at what data models really are they are in cognitive psychology today described as points and lines connecting points. Exactly the description for graph. One of my favorite books which I'm still reading these days is called Mind in Motion, our Action Shapes Thought. It's written by Barbara Trasky who is a professor of psychology at Stanford. And one of her nine laws of conditions is spatial thinking is the foundation of abstract thought. Well, if you look to the right on this picture here you'll see where the graph movements started really. It was back in 1736 where the king of Prussia wanted to solve a logistics problem how to cross the city of Königsback which has seven bridges without using any of the bridges more than once. This gave birth to the mathematical discipline of graph theory which is well-defined, well-described algorithms on top of graph structures. But the real benefits of graph is it is easy to understand. It talks to us directly. It is a mirror of the structures that we have after the cognition has taken place in our mind inside our brains. Now this is a simple financial investment management high level graph. Those of you who know that kind of business can have a lot later. The way I draw these things is a very simplistic approach. Visual syntax defined by me, the round ones are concepts, rounded rectangles are properties you can also use example values on terms of time and three different kinds of relationships one to one, one to many and many to many. So a data model can look like this. This is the movies and persons data model again. But notice one thing in particular we have a lot of relationships, visual here. All of them have names. This is one of the big differences to classic relational modeling. What relationships are in relational parlance is dependencies, functional dependencies. But we did not really name dependencies. For instance, the fact that a person has a name. Sort of just implicitly assume that yes, there was something like that going on. But in graph, they are real relationships. If you have the mathematical approach to graph theory is they are called itches, but in France people normally call them relationships. And named relationships is what matters most in graph data modeling. This is the primary takeaway really. You have to visualize the relationships and you have to name them. That's really the secrets. So that was the what and the why and the conclusion is this is a property graph data model. We have notes and relationships. Notes, in this example, have properties. And some properties have specific roles. Notice the italics and the bold face names which are used to handle identity and weakness. So that brings us to the next issue. What are the differences between classic data modeling and graph data modeling? And to answer the question, are there any? Yes, there are. But they're not as dramatic as you would think. Some of you who have been with this as long as I have will remember Peter Chen's entity attribute relationship model which he published in 1976. And if you just lean back and look at this, what do you see? I see a graph on you. We have some things that are connected. The connections have names. That's in the depart imp or imp-debt kind of relationships. And the project, for instance, has name, location and number. Now this is nothing else than a property graph. There's so many parallels between Peter Chen's data model and the property graph data model that it's really what the answer is all about. But there are some more details. When you work with graph data models, you have to think about visualization. It is a visual approach. That's why approach-graph data models talk to people because we are visual creatures. 80% of our perception is visual. So we look for structure in what we see. The other big differentiator is highly connected data. I'll show you an example later of the Panama Papers. And normalization is handled very differently. You can also do many to many relationships with ease in graph data modeling. You have to learn to think in past. You know, how to navigate a graph structure going from one place to another, crossing say five, six, seven node types and relationships on the way. And labels and types is the graph data terminology for entity types, object types. The schema is also an issue to talk about. So we'll come back to that a little bit. Because actually, as I said, you don't actually have to write a schema to build a graph database. You can do it pretty much without a schema, but you can also do it the other way around. So all in all, there are some new opportunities for the data model. And let's have a look at just a few of those issues. First, you have to graph things. And to do that, you have to think spatial. You have to describe context and use clear language and be close to the business. And that's sort of what I started off saying. This is my mission. I want data models to be close to the business and I want them to be visual, intuitive, easy to grasp. And that's what this is all about. So this is a graph data model. It's on the concept model level. We have some different types here. We have the nodes and we have the properties. But it's also a graph by itself and all relationships even between nodes and properties are visualized in this modeling example. And we'll come back to what the process looks like for producing a, let's call it normalize graph data model, which is one of those. The trick is, I can say already now is to look at the relationships because the relationships tell you what is going on. We'll come back to that. I promised a graph data modeling example. And it's here. It's perhaps not clear to everybody what is going on here, but you know, a bit black blob sort of in the middle between the officer and entity. Well, that is actually around 800 different relationship types connecting officers of entities with entities. And that's not a very elegant data model. Maybe, you know, people from the relation side or such a world, that's then, you know, relationship type kind of relationship so that we would have a relationship type on the relationship telling this is a CEO, this is a CEO or whatever. But this works also, you know, you can have these 800 different relationship types and you can connect anything that needs to be connected. So that's the highly connected data. That's a difference, right? We do not have to worry about the multi-level joints anymore. So what do we have to worry about then? This is a famous relational model example from Chris States takes group introductions, database systems, suppliers and parts and supplier parts. Now, if you look at that, where are the relationships? Well, they are, you know, actually hidden in the supplier parts table, right? So how do we handle this? Well, we could take those three tables here and draw them as the concept maps and on that here now. Then I could say, okay, but we know that there are some implicit relationships in this model because of the same names appearing across different tables. So let's visualize those relationships. Name the relationships is an extra step. Excuse me, and as you can see, I mean explicitly name the relationships. All other relationships because what the relationships will do for us is to help us identify what should become notes and what should become properties. The trick is, as is used in other kinds of modeling approaches also. For instance, in the business rules, comes the modeling things that one rust promotes. If a relationship name implies an action of some kind, for instance, is to be supplied, well, that is a good indicator of here is something going on, which is actually part of the business process, sorry, that involves parts and suppliers. Passive kinds of relationships like has or is a or something like that, they do not imply any business process going on. So they are a passive function of dependencies linking properties to notes. So we can draw that data model like this. We can also do it like this in a classic a crow foot type of diagram. Or we can do a project graph model. This is actually the very same model. We actually created the city object type on top also because I think that's a good way to handle this particular data model. So, normalization in graph data is visualizing dependencies. That'll give you a deep understanding of the functional dependency structure. Use name relationships between all concepts to get to understand the semantics. And use identity and uniqueness visualization on the graph diagrams to really set the context in very precise ways. This is really the purpose of normalization. We need to get the structure right. We need to get identity and uniqueness right. We need to get the relationship right. And we need to put the properties in the right places. And we can let you do it. So the next little part is one about artisanship. You already saw here that we do what not to care for normalization structures and identity and uniqueness and so on. But what else? Who would really need to sort of care for data models in detail as we did before? Well, my take on that is that data is data, right? But to understand data, you need to understand the structure and meaning. So we need to have the structure and meaning reasonably well in place. And the fact is that data balls can be non-existent. They can be bad. They can be so, so they can be good. One that makes a good data model, you might ask. And that's what we're going to look at here. Now, as Shannon said, I'm from Europe. Near Europe, we have a movement called, oops, I need to go back, sorry. No, I'll come back to that. This is misplaced, sorry about that. So when I describe graph data modeling in detail as for instance in the online training classes, I have two processes lined up. One I call the supermodel track. The other is what I call the fast track. Because reality is that we need to either support a very compliant, tightly governed and controlled approach to a data model. If you are a government agency or if you are in a financial institution and so on, you have to go through detailed steps like in the supermodel track in the middle here, like worry about the business concepts, get the meaningful connections and knowledge right, do some sub-setting maybe, and then get into a solution data model process where you do some ideation from design thinking really connect, validate the governable structures and knowledge graphs coming out of that. And that's an extension process of the conceptual model. Then you need to do some transforms to get a physical database out of it. On the solution data model level, you're worrying about scope, new stuff, abstractions, lineage, naming, relationships, uniqueness, identities, and cut analysis, and data quality improvements. That's a lot of work. In the fast track, what you do is load and transform some data and then look at what you loaded and optimize it. Now on the top, I have written data models to be read cycle, that's because in my head, a lot of what is going on these days is that we're actually reusing data models. We may be taking data out of a relational database to find somebody who has done a relation data model and reuse that in a graph context. And you can do that with a lot of other kinds of data models like UML and what have you. And so what it boils down to is that your degree of recycling of data models varies and your care about the design of the solution model varies a lot because in the fast track, you don't really care until later. So data models consist of, well, we have seen it. We have object types, we have properties, we have dependencies which are functional dependencies of between objects. We have cardinalities, we have uniqueness, we have identity and we have data types. So those atoms and molecules are sort of the same regardless of which kind of data model we are talking about. So they need the same kind of care, right? But in the graph database world, we can also do pointers. That's a unique opportunity. You can actually relate structures using, for instance, a next kind of relationship to link orders probably over time. So that's sort of a way to do time series in an easy way. Or you can do prior, you can do first or last, so forth. So that's another opportunity that you have. You need to worry about data structures still. This is actually taken from the official internet standard for email. This is as the standard is described. But you could mess up. Mess up it's a little bit, reduce the complexity and end up maybe in a very condensed data model like this. We do that all the time in relation. And you have to consider doing things like that also in graph. And then we have many, too many relationships. Well, in relational, you basically don't do them, right? But then you do build relationship tables called bridge tables. And you do also in Star Scamers have factless fact tables and things like that. But in reality, if you ask me, non-information bearing many, too many relationships are relatively seldom in real life. Most often, many, too many relationships do carry some bits of information. So they are somewhat real. But in the graph, you're not forced to have anything. You can do a simple, many, too many relationship without any additional modeling and just do it. And that is something to consider in some situations. So there's still some care to be exercised when we design graph data models. The last issue here is about agility. I mentioned that you can use graph databases in a very agile manner. You can just load some data, which is schema less. And then you can evolve a schema eventually by stepwise refinements, refactoring of the database. But you can also work the schema first as you are used to in SQL. Now, what I wanted to say about European data architectures is that we have something phenomenal here in Europe called full-scale data architecture, which looks like this. It's actually four data quadrants across two dimensions, data delivery, data consumption, on one side and systematic governance versus opportunistic approaches, the other side, so that gives you the four quadrants. So in the first quadrant called controlization, that's the tightly controlled and governed environment. On the second data quadrant is the duration. You have the data warehouse business intelligence area, really. In the third data quadrant, the collection, you have the data lake, and in the fourth quadrant, you have the discovery going on on things coming primarily from the data lake or being derived from the data warehouse. Now, this we call the full-scale data architecture. Now, the idea is that whatever you do, you're actually faced by this angry bull because you have two challenges. You have quality on one side and you have flexibility on the other side. And you have to grab the bull by the horns and move them in one of the two directions. You cannot move them in both directions at the same time. That's not doable, so you have to make up your mind, so you have to go for quality or flexibility. You can do both at the same time. So that's full-scale data architecture in five easy sentences. So let's be very agile here. Let's suppose we use Neo4j, which is a particular product. And as you can see here, there are numerous ways of getting data into Neo4j, so you can really, very quickly load data in very simple manners and then you get data in. But you have to think about what's the quality of the names of tables and columns if you had a relational source. And what is the quality of the relationship names if you have them? Because in real life, SQL databases contain clandestine relationships, which are not sort of easy to spot because there is nothing indicating that there is a relationship and not even the same names being used across different tables. You have implicit relationships going on and the same names into tables, yes, but nothing else than an index to indicate a relationship. Or you have the explicit relationships, the front key relationships. And these numbers here are actually from a simple little survey that I did. So you can see we do not, from the data, know all we need to know about the relationships. And the quality of the names are typically generated by data modeling tools. So it's from table to table when I'll describe between stuff like that. So there is definitely some human aspects of data modeling. Even if we can get data in, we need to make some human adjustments. But fortunately in these environments, you can do a lot of profiling very easy. What did I note? For instance, what is the schema that we have loaded? You can infer that from the data. This is a Neo4j example. This is the same movie example with persons and movies and some relationships between them. So that's what the schema looks like. Ah, no, I understand better, right? How many node types and relationships do I have whether I can count them? This is a Cypher command, much like a SQL command. I'm not sure, really. I can evaluate the uniqueness of a property within a label. I mean, how unique is this candidate key? This is the code for doing that, it's just a query. What properties do we have on relationships? Well, this is the list. We have a roles, property on acted in, and that's nice. So on the acted in relationship, we know what the role was of the Jekyll, right? How about cutting analysis? Well, this is a Cypher command to infer cutting analysis from the data. So what you see here is the problematic relationships. Excuse me, I'll skip that slide here. Fortunately, refactoring your graph is easy. You don't have to unload reloads with a schema change in between. This is Neo-J Excel also, and they have a library called APOC, which is really awesome procedures on Cypher. That's what the name means. And you can see there's an APOC refactor on merge nodes function, for instance, that you can do merging of nodes with, and you can do several kinds of things on way as you go. So restructure in place is easy. So that gives agility a good chance here. So to summarize the graph data modeling approach is if you get up in the helicopter, really very simple. Here's a list of concepts. Let's connect the concepts and name the relationships. Having done that, we can do a structure data model because we need to consider what kinds of relationships we have, what are the active ones. We assign arrow heads to those because they are most likely to be relationships between, for instance, segment and company, country and company in some object relationships, while the other ones are simple property dependencies. Now having done that, we can visualize the properties and we can start to worry about the identities and uniqueness criteria, visualize that also, and that gives us a very governable data model. We cannot run that as a project graphs, we need to reduce it to a project graph data model like this, which is actually just folding the properties through the nodes when they belong. So that's really graph data modeling in a nutshell. We have a set of four courses going through all of this on training.diversity.net, I developed them. So I recommend them obviously. And this is me. Thank you, Shannon, very much for making this possible and thank you all for coming and I think we have some time for questions. Indeed, Thomas, thank you so much for this great presentation and a lot of information here. Just a reminder and to answer the most commonly asked questions, I will be sending a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording and anything else requested throughout the webinar. So diving in here, Thomas, it looks similar to ORM, but is ORM, I can speak today. ORM is Richard. Yes, you can indeed argue that if you mean with ORM the fact modeling kind of things that are going on, it is a very rich environment. My take on that is that sometimes you need that kind of precision and if that is what you need, then do that. But if you don't need that, don't do it, stay on the simple concept modeling kind of level and map that easily to a proper graph data model. And in your supplier part model, why did you resolve supplier part? Since relationships can have properties, is that necessary? No, no. No, it's actually not necessary with properties on relationships. In fact, many live graph databases don't have it and if you see them, it's typically things like data that really refer to the relationship itself. For instance, relationship between owners and properties could have an ownership percentage on the relationship. Things like that. What about modeling with ontologies? Yeah, that's an interesting question. I'm actually looking at that in quite some detail. As part of this standardization, I found that I'm participating in in the SQL community. We need to create a graph query stand up that is as broad as possible. And graph, the semantic graph community is very large. They have a lot of ontologies and other interesting RDF stores already running and have been running for years and doing really good stuff. So we need to think about how to get that bridge built between those two communities because the SQL property graph standard is a property graph standard. So we need to do some intelligent bridging, but there are some proposals already for how to do that. If you're interested, I can look at the search for something called RDF Star and Spark Proog Star, which are proposals for extension of the W3C standard with, for instance, the capability for having properties on relationships which they don't have to do. I love it. So we've got time for a few more questions here. So please delve more into data quality being improved through graph profiling. Yes, sir. That's really a beautiful thing. If you go to the online training classes, you'll see some examples of what you can actually do in very simple manner. I've been doing data quality since around the last 20 years using data quality tools. My first one was Avelino Discovery, by the way. But, you know, that is not easy doing data quality projects, examinations and problem fixing is necessarily a very agile thing you have to be able to do. And the flexibility of the graph database is so great help to people doing data quality analytics that you cannot really do that without graph. Sparkle is a W3C standard for querying RDF graph database. There's a comment in there. Anything you want to add to that? Yes, what seems to be happening is, you know, that the SQL committee has selected a, what we call it, to base its framework for graph query support in SQL, mostly on the property graph model as materialized in Cypher, it seems. Cypher has this concept of ASCII art, they call it, where you visualize path structures in the graph as little graph pictures, you might say, constructed using normal letters and little arrows and things like that. And that is a very powerful concept and that's the one that's going to survive. And what will happen in details when we think about the Gremlins side, for instance, nobody knows yet, but we are certainly going to think a lot about how to make this as broad a solution as possible. Thomas, how do you relate data? Three is not PK or FK? Sorry, can you repeat that? Yeah, so how do you, how do you relate it data? Three is not PK or FK? Ah, yes, yes. Well, you just tell it to relate, you know, using some kind of criteria, you know, in the end, there is no concept necessarily of a primary key in the graph database. You're not forced to have primary keys, you're not forced to have foreign keys. Any criteria for connecting two nodes will be, you know, done. That's flexible, right? So, you know, a common question, you know, especially are there any software tools that can use for graph modeling? Too few, I'm afraid. What I use myself is normal, I also use a concept mapping tool a lot. But there are tools coming out. If you want to have a commercial product to look at, Google Grapho, graph.fo, they do graph visualization, graph model visualization for both semantics and projectors as a new product from data.world. And there are a couple of other things. Hackalase is one of the NoSQL data modeling tools. They have graph support as well. And there's a pure Neo4j graph data modeling tool coming out also, Nodeva in the US. So, I expect that to move fast, really fast. As soon as we have the clear picture of the forthcoming standards, that will really get things to move because, you know, the problem is today in project graph, there's not a whole lot of the schema syntax available. So, what should the data modeling tool do? So, if somebody is looking to start a new company, now this would be a good idea then. Yeah, and I've got some ideas that I can give you. All right, so Thomas, you know, are there any different analysis techniques that have merged from a graph approach? Yes, I'd say you saw me use what is really basically concept maps. And you also heard me comment, you know, that one of the beauties about graph data models is that the final physical graph database looks a whole lot like a concept model. And, you know, how do you extract concept models? Well, the way I've been doing it the last 20 years is to use concept mapping in brainstorming sessions together with users. That works, people can relate to that because it's intuitively easy to understand what a concept graph is. The other thing that's going on which is really very interesting is the natural language processing which actually can produce concept models as a result of the NLP processing of text. That can give you a very good starting point for building a graph data model. All right, well, Thomas, this does bring us to the top of the hour. I'm afraid that all the time we have for today. Thank you. We do have a couple other questions and maybe I can shoot over to you that have come in. But, Thomas, thank you so much, especially for this late evening webinar for you. I really appreciate it. And thanks to all of our attendees for joining us and being so engaged in everything that we do. We really love the questions coming in. Just a reminder, I will send a follow-up email to everybody by end of day Thursday with links to the slides and links to the recording of the session as well. Thomas, thank you so much and I hope you all have a great day. Thank you. You too. Thanks, everybody.