 I'm going to talk about graph data. It's a weird thing, right? It's going to be an excellent hands-on session this afternoon using Neo4j. I spent most of my time in the guts of Neo4j doing low-level big twiddling, as my wife describes it. But what's really amazing, about a year ago, I saw a chat called James Fowler give a talk about health informatics. And James was using graphs, connecting data structures, to map pathogens like obesity, for example. And he was coming up with some really crazy, interesting, counter-intuitive results by using graph theory to be applied to a dataset to find out how obesity spreads. For what it's worth, the weird thing is, if you want your kid's friends to be thin, you should be thin. Because your obesity doesn't too much affect your kids. Weird! And I was like, wait a minute. This is interesting. And this is fascinating stuff, because I thought all the clever stuff in graph technology was domain, model, affinity, and then the stuff that I do with my team, which is actually writing databases. That's proper manly nerd stuff, if that's not too much of it, and obviously more on. You know what I mean? It's like proper geeky stuff. But then when I heard James speak, he reminded me about just how awesome informatics is, and how amazing the whole graph is for finding out about what's going on in the world. OK, I'm going to get more into this. So as it was like detour from my normal day job, I started reading up on graph theory, remembering all those graph algorithms that we forgot from university. The ones that you kind of slept through with the boring old professor using a chalk board. Remember that guy? Oh boy. But anyway, it turns out there's a grown-up. These things are fascinating. And I want to share with you today some of the kind of fascinating stuff that's happening in the world of graphs. By implication, graph databases. So I want to talk about a bit of a rover. I've got to get my 10,000 steps in. So I want to talk a little bit about increasing data. So I read some data conferences, a lot of data stuff going on. And I want to talk about accessing data. And then I want to talk about graph models, the various graph models that are becoming prevalent today. And then actually jump into a bit of graph theory. Don't worry, there won't be too much maths. Yes, this is a plural people. So that's that English domain expertise thing going on again. That joke is going to be worth it about 30 seconds from now. But it's going to go through the trough of disillusionments. And about 10 minutes from now it's going to be funny, isn't it? Mark my words. So we're going to do some graph theory for predictive analysis. So we're going to look at some data and predict how it might evolve. And we're going to see that graph theories are absolutely amazing for doing predictions on data. And then we're going to look around and we're going to look at graph pattern matching. And then retrospective analysis in near real-time on data for firm and pocket. And then I'll bring in facts that were tied into some interesting things that have happened more recently around for a paper graph search. And then free stuff. That's such a cheap thing to do, isn't it? At the end you'll get free stuff. If you don't walk out like this dude, he's a bowing tool. I'm going to find that bowing guy and find out what's so fascinating in his talk. Heck free, heck me, and then walk out. Here we've been here. This isn't what we're doing anymore. We've all been in that situation where you've done the upside down left outer up and drawing through 17 tables just to change this flag from truth to false. We're not in this situation anymore. We have alternative data models. And this conference really embodies the spirit of those alternative data models that are the best fit for the system you're building. And in that umbrella of no sequel, I was just in promote store. He calls this out very well. He says that we have the notion that I would have databases composed of the key value stores, the column stores, and the document stores. It's cute, isn't it? Of course, here, my little geek point here is people argue, you've got Adrian, who'll tell you Cassandra is the most scalable column store. This is the most scalable column store people. This is the British Museum. That's columns where we store stuff that we stole. And when we expand it, it could be the new wing, right? That's how it is up to stairs with me. Now, we've got the Greek stuff. We've got the Egyptian stuff. It's amazing. And it's free to get in, right, dear? Most people don't get in. It's all stolen, right? That's why we have security guards. It's to stop people reverse stealing, which kind of doesn't seem to come on that. Anyway, don't get me going down that track. Make it serious today. One of my colleagues is in the room. He's going to report that to my boss. If I don't mind, he can use you. So, we've got these things called Angular databases, and he's writing part by Martin Fowler. There's a lot of algorithm databases, but they're good when the way that you store data and the way you query it is a find. That is when you store algorithm retriever, everything goes swimmingly. But when you want to chop that data, when you want to look at it in different dimensions, then you have to often resort to external means to do that kind of chopping and gnashing data for you. Which is why algorithm databases tend to speak so prevalently about processing techniques like MapReducing. You often couple your algorithm data store with some external processing like a patch you could do. That's a find-by-thing, right? But it's a bit like the kind of prison break. Where your data is happy in the database, and then suddenly you kind of bust it out of prison, running through the doof, and then get some insight into your data and then maybe stick it back in. And again, that's a find-by-thing to do, a doof o hand, and it will give you that high throughput, because it's typically a very amenable to parallelism, but similarly it will be at relatively high latency. And this is where we come from. We come from a situation where these kind of data stores, these kind of data processing techniques grew up where the biggest problem we had in data was size and growth. So on the most simple thing, really kind of here, a group got it ahead of scheme because we were worried that data was getting larger and larger and that was going to negatively impact the kind of traditional relational databases that we're all used to use. And that really isn't still a problem, right? Data is still growing, growing, growing. We're storing and processing each year more data than we've ever had before. But that's not the only access along which data complexity is growing. If complexity is not simply a function of size or children or any of that stuff, you don't want any of the 17Vs of data that God will give you. Data complexity is also a function of uniformity. And uniform or disuniform, just letting myself down with English there, I don't actually know the opposite of uniform in English. So if anyone knows that word, I'm going to tell me offline that would be lovely. Or indeed, how connected that data is. The aggregate model to false classes promoted eventually in this session previously is that there's no notion of connectivity between records. It's something you have to kind of, by convention, make up yourself and manage for yourself. But actually data is connected. Habitually data is connected. When I go and see my medical practitioner free at the point of charge, by the way, mmm, that's it. Ah, come on. I tease because I love. I'm not in this state though, right? I mean, you guys are kind of basically safe. Like, the strips around the edge isn't safe for me to make these jokes, right? It's just a weird bit in the middle with guns that I can't get used to. Oh, blimey. It's a great mistake this bit. I was doing a road trip last year through some of the flyover stages. Lovely, beautiful places. I was having a lovely time with a couple of guys with funny hats and stuff. I was like, do you ride horses? I was like, no, don't be daft. It don't meant us to ride horses, it exists. Suddenly, not so many friends in that part. Anyway, um, back on data. So, we've got this. I'm slightly safe with data, right? We've got to reach this fork in the road, if you like. It's got to be a really interesting qualification point in the history of data management. The path of house is really very distinct. We can go left. We can denormalise data into aggregate. And then we live in a world where denormalised data, keys and values, or common families, or documents are stored as independent, atomic units of data out of database, simple data model, but then we have to use some processing technique in order to gain insight. So, we're going to take that data and run it for our processing infrastructure and gain insight that way. The right fork in the road takes us to a completely different model. It takes us to a model that we have a richer data model where we have a very query-centric method. And it's weird, right? This right fork in the road is shared by graph databases and relational databases where you build a high-fidelity model and you ask questions of that model and it gives you insight that way. You tend to have, at least in the case of graph databases, there is much more about expressing power and doing traversals over a linked data structure than it is about ripping data out from the history of the dupestopsies machine and group forcing insight that way. So, this is the fork in the road that we're going to take in this session. This is the world in which we live. This is the world in which I live. I live kind of in this thing. That there, this was like a map of stabbings. This would be much more prevalent, so I live in the stabby part of London. That twice we don't have handguns, right? At least we've got a churchy with a knife itself. So, this is the stabby part of London where I live. Here is London Bridge Station, which is where the Neo4j office is in London. And up here is Paddington Station. Now, some of you guys have been through Paddington Station. Now we get the link up to Heathrow Airport. So, if you guys do nothing about London or London's tube network or grout or anything, I bet I can still ask this question of you and you'll give me an answer. What's the best way for me to get from Paddington Station, which is connected to Heathrow Airport by a pass train, to London Bridge? What would you do? You said, okay, here's Paddington and there's this green and yellow line, so if I go down here, perhaps go up to this station monument and then change on to the black line because I'm in the bridge. And that is a perfectly reasonable path if you're a complete tourist idiot. The green and yellow line is shit. Never get on it, right? It's the worst line ever. It's atrocious. It's smile, it breaks down all the time. So that would be a problem of my own resentments to having wasted lots of my life on that line. That would be considered a lot of work. This one would be kind of a type or frustration of every metric you're describing a path quite expensive. But I'm thinking about the lowest cost path actually is to go from Paddington to Baker Street and then go on this silver line in the Jubilee Line out of London Bridge. That's the way to do it, just in case you're ever coming to visit to get back at me for my crappy jokes. So any of you who visit, we're lovely and friendly but notice I know what's causing what effects here but the stabbing part is significantly less connectivity. Is that because of the stabbing? I don't know, maybe if we were a bit more connected we would be so frustrated and shanky each other all the time. Do you notice that the stabbing kept happening on buses? This is not the kind of violent metaphor for graphs that I really wanted to project. But anyway, let's go on. The polygraph model. Even if you knew nothing about graphs you were just able to solve what is actually quite a sophisticated graph problem. You probably didn't know this perhaps but you just solved it using something like Baxter's algorithm or the ASTAR algorithm. Those algorithms that you were taught at university and immediately forgot when you left school and got real jobs. The model that we have in most graph libraries is called a polygraph. It's a very simple restressing model. The nodes are kind of like containers for documents and inside a node you put properties and properties are key value pairs and connecting those nodes you have relationships and relationships are directed, they are named and they can also contain properties. For example, you put weights and costs on an edge if you want to do those kind of algorithms. Using these simple abstractions you can actually build up various sophisticated models. You can model the London Tube Network very effectively but graphs are often used to model public transports and use for meaning of that kind of stuff. So, actually, although you've come from a talk on graph theory, I have a mission which is kind of like reverse cultural imperialism. You've sent us friends this is our shop back across your bounds. I'm going to teach you about Doctor Who. Who knows Doctor Who? Which Doctor Who more of them? All of them. Good, good, good. I don't know Doctor Who. Let me just set the context. It is the longest running science fiction TV show in the world. Perhaps, we don't know for sure. For example, much longer running then, what do you have here? Star Trek? Make it the Louvre? Yeah, okay, yeah. Johnnie, come later this far as we're concerned. So, Doctor Who it is a universe around this chap called The Doctor. The Doctor is a humanoid figure. He's not actually human. He's a traveller in time and space. He goes around the universe putting right things that have gone wrong. He is completely tooled up though with a screwdriver with which he saw all those universal universes. Not selling it brilliantly now, right? So, The Doctor is from this planet Gallifrey. And that's the simplest graph we can draw. Doctor from Gallifrey. Notice the direction of this relationship here. It's not Gallifrey from Doctor. It's Doctor from Gallifrey. And now you know a piece of geek trivia that you didn't know before you came into the room, right? This is like a surrogate picture. Now, The Doctor is made up of an impetuous Gallifrey and an impetuous Time Lord. And while most Gallifreyans are content to sit around watching the universe kind of drift past or survey the body, they have in fact invented the ability to travel in time and space. The Doctor is like, well, actually it would be far more exciting if I travelled in time and space and had an adventure every week. Who would have thought it? Every week in adventure. So what's he doing? He steals a time machine. This is called a TARDIS. A timing relative to dimension in space. Second geek fact for you. So he steals a TARDIS and now he can battle around the universe having adventures putting right things that have gone wrong and so on. And then of course, going around the universe putting right things that have gone wrong, The Doctor starts to make enemies. So it's kind of like an anti-social network. So he makes enemies of the Dalits, he makes enemies of these guys, the Sontarns. He makes enemies of these guys, the Sontarns. And this actually is a speaker of Maddenfine. So I stole this slide from my colleague Ian Bobkinson who's also a Doctor Who nerd. And he put the Sontarns in, not because they're particularly popular enemies, because he says I look like one. Which, you know, is that a compliment? I can't tell. I need to be shorter. That's saying I'm already short, but I can do with it. But it's all time relative. It's all time relative. He's also quite a needy fellow of the Doctor. He tends to travel with his companions. So up until recently he was travelling with these guys. This is Rory and this is Amy. Rory is a companion of the Doctor and Amy is a companion of the Doctor as well. And these guys have their own little thing going on. It says that they love each other. Notice Amy loves Rory, Rory loves Amy. Love can be unrequited. And you can't hold all that in the graph. Just because Rory loves Amy doesn't mean the reciprocal is true. In this case it's very much true. They love each other, they're married, they have a daughter, the daughter's river song. Who eventually becomes the Doctor's wife? Leave me hanging, why don't you? I'm sorry about that. When the Canadians invade, I'll be like yeah, I'm a joke. And then there is the real world of Doctor Who. Don't worry, I'm not kind of just losing the plot here. Doctor Who does have a real world, right? It's the real world of the supply chain. It's the real world of the episodes that the BBC put together in the package, got on our TV sets and our DVDs. It's the real world where the actors come together with the directors and the scriptwriter and the guy who makes the coffee and sandwiches. So all these things come together in another dimension if you like of data, which is the supply chain of the logistics stuff for the show. So now, even if you don't know any Doctor Who, I can ask you questions like, in which episode did you aim to battle the Daleks and you'd be able to answer that, not simply because this episode has the word Daleks in it, but in case you just follow the lines. And that's what a graph database does. It follows the lines, except it follows the lines very, very quickly, far more quickly than I can do with a laser pointer. On my kind of reasonable laptop, I can get about a million or so traversals per second per clue. So I can explore rather a lot of graph very quickly or I can go very deep into a graph in a reasonable kind of OOTP timeframe. They're also super lovely for design. This is actually the original designer by Doctor Who Dataset. In a graph database, what you draw is what you store. You don't need to do the voodoo sacrifice of chicken to the gods and then de-normalise the 17 spindles, the other oracle rag. You draw and you store and you query. It's very straightforward. The domain model is a data file to your data, which brings us now finally to predictive analytics. So here's this guy, Oiler, who invented a graph theory 275 years ago. He is, to us as computer scientists and mathematicians, what shakes theories to students of English literature. That is some bastard that's putting out computer science courses just to make them hard. Or so I thought. So I thought. Anyway, so it turns out he meant a graph theory, not just for a lab, but he has a real war problem. He has the problem of the seven bridges of Cunigsberg. The question posed is, is it possible to cross each of the seven bridges of Cunigsberg without retracing your steps? This is the real problem. Of course, Google paid homage to that recently. Let's pray that graph processing infrastructure. So what does Oiler do? Well, he takes this physical problem, this noisy messy real war problem, and he decomposes it into a diagrammatic version of that problem. I found a logical representation on top of which he then imposes a mathematical representation. In fact, what he does is the first structured systems analysis and design. He does what we do. Every day. He takes a messy real war problem inarticulately described to us by business stakeholders who are basically bubbling chimps. I think as a chief one, isn't it? But it's true. And we decompose it to some logical representation which we typically call a design or a unit test or that kind of stuff in software. And finally, we come up with executable specification which for us in the most part is some executable software for Oiler or some mathematics. And using that, he was able to determine that no, in fact, it is not possible to traverse the seven bridges of Fonysburg without retracing your step. Which brings us to local properties. This guy is definitely about to do a stabbing. This is the name of where I live in southeast London which is splendid. I notice it. It sells English food. What are you doing? It's horrible. It's like the planet is on the planet. Anyway, local properties. Funny thing about that is things that happen in the micro are super important because they change the graph at the macro level. So there's notion of a local property in the graph and the easiest local property to get experience is the notion of triad enclosure. And you have to say in that way, it's kind of like when people talk about Haskell and they say more ads than you, right? I mean, it's like Harry Potter when they say that word. What triad enclosure really means is make triangles. But if you're a mathematician, make triangles seems a bit kind of lame. So they have this fancy word, triad true triad enclosure, which is just make triangles. In a graph, particularly in graphs there are more humans. They want to close off triangles. So if you look at this, this is from the South Park cartoon. Something I'm a huge fan of. I'm a huge fan of the ethics of Eric Carpenter. So here we have a potential little social network. Call I Up who's a friend of staff and Call I Up who's a friend of people. Even as humans now, there seems to be a tension there, right? If you've got two friends and you've got a couple of mates, at some point you've got to introduce them. And because you like both those friends of yours, they're going to like each other as well. So you get to close the triangle, right? So Carl's a friend of staff, Carl's a friend of clinic, Stan and Kenny become friends. That seems fun to us actually, right? That's kind of fun. Good humans. But equally, there's this notion of structural balance in triad enclosures. So while a triangle containing three positive sentiments, three friends is quite stable, right? That feels quite stable. Equally, we can try and close the triangle this way. So we've got Carlman, who is somewhat ethically challenged even for an annual point, and he's friends with Eric Carpenter and he's an enemy of Eric Carpenter this week. Now, of course, we can try to close this triangle, create a triangle, enclosure, but I say, well, Carlman, friend of Craig, anyway, friend of friends. But this feels awkward. He even kind of, you know, feels like saying friend, like, Eric, Eric, they're there to eat, turn the douchebag. Come on. That's not bad, right? I'm like, friends of the marriage and tweaks my friend. So don't call them a turn the douchebag. It feels like an awkward kind of triangle. So the graph resists this. It's an unbalanced closure. Whereas, actually, this is a balanced closure where Carlman and Craig are friends and they both dislike tweak. I'm not saying this is a positive outcome for humankind, but it does, at least, feel like it's a balanced structure in the graph, right? So these two guys were now ganged up on this guy. It doesn't bother humans as a species, does it? Of course, to balance, otherwise, we could go back to this nice, stable structure here by having three friends there. Both stable, I feel like, low energy parts of the graph. So structural balance is a key predictor technique. And what's more, it's domain agnostic, which is great, right? Graphs don't really know about school yard tips or that kind of stuff. But we can use them to, for example, think about how geopolitics will evolve. So here's a retrospective predictive example, right? So here we are sometime in the mid 1800s with the great houses of Europe. Notice you guys aren't on this map, because you're not in Europe. And frankly, at that time, right? So here we are, the great houses of Europe. This, my friends, is the good old days. The red arrows indicate enemy relationships. The black arrows indicate how this is the way of things. Is this error to think? I should have got massive waiting on it, right? Now the Brits and the French share aircraft carriers. It's a bit problematic. Can we borrow the aircraft carrier next Thursday? Why? No reason. Anyway. We can use this notion of balanced triangle closures to predict how they're going to evolve. Ultimately, we're going to be able to predict how more and more one starts. Which is going to get wind for graph theory, being lost for human power. So here we go. There's not a bunch of nodes here. Let's start to create triangles. First thing, let's bring Italy in. This is a stable triangle closure. Austria, Germany, Italy. Now there's friend, friend, friend. We're already getting a bit ominous, isn't it? When Germany bodies up with these guys, it always seems to have ended in tears. So now we've got friend relationship. Now we've got this lapse between Samson and Russia, and they become friends as well. This is not so good. This feels unstable. These guys being friends seem to be geopolitically unstable. Then what happens? That is the weirdest thing in the history of the world. That is called the entente courier. It's a document sign where the British said to the French, okay, stop kicking your arses with long bows for a few minutes. A paraphrase, right? A trip in French, which is basically in modern terms cryptography. Cool, won't it? But this is how. This feels weird, right? Because like weirdly, France is saying hey, Russia, you're nice. Hey, Britain, you're nice. But Russia and Britain still really aren't seeing eye to eye. So that doesn't feel stable. It feels like an unstable crowded closure. So actually the force is acting on the graph. They make Russia and the UK into allies. And then if we complete making closure, just making triangles, right? That's all we're doing here. We're making triangles in the graph. And the graph naturally bifocates into these kind of two sets of enemies which all have friendships between them and nothing but enemy relationships between them. These are all now stable crowded closures. The graph didn't know that it was predicting the outcome of World War I. But this now is the starting condition for World War I. Predicted by graph theory, which is I call that a stable. So this exactly came from a phenomenal book called Networks, Cows and Markets. I encourage you all to get copies. The authors make it available free on the web from the University of Ada. And you can buy it on real money at Amazon. A phenomenal book is A Impact Undergraduate Economist. So it's a picture at just the right level for kind of a slot because we can get the maths enough and it's just amazing. And they work out and fall in that book. Easy and climb up. Brilliant book, brilliant book. Please get it. There is this notion of strong data closure. So relationships don't just have positive and negative sentiments, but they can have strengths applied to them. How much do I like test someone? And we can actually factor that in this notion of strong data trying to closure. So in this case we can have the notion of the O'Kelly's standing apartment. And Kelly is friends with standing apartment. Kelly's quite a nice chap. Standing apartment kind of get along okay. So they're still friends. Well, they're not very friends. In fact, you know, about standing calls him, he calls him, something else. It's not super, super friendly. But it's probably not outright enemy. So it's kind of a weak friendship going on in there. Now, perversity again, in the same way that these micro level things, these kind of small try to closure effect the overall structure of the graph. Weak links play a much more important role in how the graph evolves than strong links. It's another perversity and kind of thing that talks me out on this graph being this stuff. With weak links tend to bridge neighbourhoods. Tend to bridge different communities in the crowd. So you can imagine weak links will be the things that, even though you've got a beautiful tree organisation on your org jobs, if you've actually analysed email traffic, you'd actually seen where the teams are, who they're really collaborating with, who they're really reporting to, who the experts are. Because you've noticed these bridge points between your teams, between your organisations. So in this case, we've got this again, we've got a friendship ground button. Stay in the crowd and close us here. And we've got this bridge between stand-up and women. Meaning that if the boys want to communicate with the girls, they have to go through these times. Stand is the only guy that's kind of manned up enough to get a girlfriend at this point. It's your eight years old, you can't really say that you're totally friends with a girl, because that's weird. Actually, I'm thirty eight years old and I still struggle with that. So it's a weak relationship, a weak friendship relationship between stand-up and women. And that acts as a bridge between these communities. And noticing these weak relationships gives you opportunities to do some more kinds of analysis based on this local bridge project. Here's a picture from the 1978 American Journal of Anthropology. World War I Karate Clubs all sorts of good stuff. Notice already in this picture you can see kind of two clumps emerging, on the left and the right. I'll give you a clue about what some of these are. So this is the node label one is the original founder and president of the University Karate Club. This idea, node 34 is a professional instructor brought into the club as its role to help the students develop more. Because there were just too many students for the original founder to continue with. You can see some kind of teasing apart going on here, something's happening. And actually, by looking for local bridges these weak links and being able to eliminate them from the graph, you can start to tease apart the graph. So they actually predict how a, in this case, how splits go to a club. Now this is a difficult problem. You've got to do this problem, it's a very hard problem. But there are statistical probabilistic methods that you can use which are far cheaper. To be able to analyse a graph and look for these local bridges and pick them apart so that the graph stops to decompose into its constituent communities. Graph theory, if you apply this local bridge property and you pick the graph apart, you find that the University Karate Club splits in two. With a bunch of people who are more connected to the original president and a bunch of people who in their networks are more connected to the new instructor. Now what's really interesting about this is graph theory gets it wrong. Because actually what happened was this. See that? This node label 9 is much more embedded in the network around the new instructor, the professional instructor, than he is around the original president. However, the guy, the guy in this case represented by node 9 was actually two weeks away to achieving his black belt under the original president. So when the club split in two as it actually eventually did number 9 went with the original president because he was so close to achieving his goal of black belt. So graph theory is a brilliant predictive aid but please don't bet your children on it. It's a probabilistically great method of seeing how things are going to evolve and not guarantee to be accurate. Ironically, don't remain a prediction about this. I don't suggest today, so I thought it was sliding. This predictive analytic stuff is going to be in the butto of productivity within two years. I was wondering how they predicted that without actually having a predictive analytic just kind of chicken and egg situation. Anyway, so this kind of predictive analytic stuff is going mainstream in the next two years or so. Then the next thing to do is look back. Sorry, don't check my time. The only thing we do with graphs which is really nice is look for patterns. So in Neo4j we have this query language called Cypher and it's about looking for patterns in data. So you can say things like find me all of the men in my database who are due to upgrade their motor vehicle and then you can spam them effectively start looking at a higher level of abstraction instead of dealing with traversing from one node to the next narrative you start to ask the data for insight based on the data of semi structures, graph data you can use that structure to your advantage to say find me stuff that looks like this. And we do that in Neo4j Cypher and the second project that we have at the company was retail analytics in one of the big UK supermarkets. So we're a bit different to you guys so you have like, you have like, you get all upset when somebody listens to your phone calls. In UK we just really don't care. We go into a supermarket and they're like, do you have a loyalty card which I can use to snoop on you and build a picture of what kind of stuff you like. And like based on that literally you'll get several dollars worth of value back over the course of your lifetime. Maybe we can stand in front of the CCTV and wave at it. We're different people. Anyway, so based on that what used to happen in the old days of this sophisticated retail recommendation system was a bunch of data would end up in an Oracle data warehouse and you know, just literally two days worth of processing it would figure out what vouchers to send me through the mail. At which point I would think oh it's spammed from the supermarket and I wouldn't really drop it in the recycle bin. Which is not a super effective way of changing my purchasing behaviour. What is a super effective way of changing your purchasing behaviour is the human contact. So supermarkets employ psychologists like lots of them. That's where they all go. Psychology graduates go from university. They're all in supermarkets up there. But they learn things and they learn that actually as humans when you place something in someone else's hand you're kind of obliged to look at it. I know this. I've worked in China for a long time. I can't read Chinese. It's a very business culture in China. So someone would place a business card in my hand and I would take it and I would stare at the pictures. Can't read them because they have pretty pictures. It's cool. But they're not psychos mostly. Generally speaking in this room we're statistically none of us are psychos. You get the part you're looking at. Now what would be nice from a supermarkets point of view is as you go through the checkout as you go through a point of sale terminal they print out a voucher for you because she puts in your hand and because you're not a psycho you take it and you read it. That is way more powerful at changing your buying behaviour than any spammed emails or stuff for your letter box or magazine adverts that you could never ever come up with. So we wanted to do that. We wanted to do real-time recommendations at any point of sale terminal. So what do we do? We built a ontology. We took a subset of the data based on the classic Walmart put beers on the end cap of the diapers aisle and you'll sell more of both on Friday nights. We liked that story. We thought we'd try it out. So we took some products. Subset of the products. In these days we took beer, napis and what we wanted to find out is what we found in the database was there was lots of people who had lots of young men who had bought beer and napis and game consoles. That's an interesting buying trend. But we also found a bunch of young men who bought beer and napis but who had not bought a game console. So what we thought was that young men, young fathers have a buying profile of beer, napis and game consoles. What we didn't realise was that could also be hardcore gamers beer, napis and game consoles. But you can't be fairly hardcore, right? If you're at that level of weird you are totally committed to call of duty in a way that's beyond normal people. So we thought generally this would be young fathers, right? Because you're like you grab the napis, you grab the beers and then you think wouldn't it be nice when the screaming, puking brat goes to bed? I'm sorry. He can't hear it, right? He's like 12,000km away. When he goes to bed, I just get to sit and relax and call of duty. Murdering people on screen is going to chill me right out after an evening of like feeding it in the diner because of all that stuff. So it's a buying. We'll stick this in the infigy. It's not this data in the infigy. We thought we would look for this pattern. Where someone who had a date of birth between these years, who we think is male, has bought beer and who has not bought a game of the song. If we didn't spot this pattern, we can then print out a voucher and say for the next two days, 20% of Xbox. Right? Great stuff. The reason we can't pre-compute that is because there's one thing that is worse than not giving me a recommendation. It's taking the piss out of me once I've bought something. The reason you can't pre-compute is taking the piss work here. It's not like doing a real transplant. It's like making a fool of me mocking me. Sorry, that's the correct image. Mocking me. So if you pre-compute that I haven't bought at Xbox, and then when I go for the check out of my UPS3, you print me a voucher for the Xbox, that enrages me. That's what I get for stabbing. So you can't do that pre-computation stuff. It's not helpful. You need to make those recommendations in the click street, if it's a web property, or in real-time, on the point-to-sale-to-line hardware in this case. So we wanted this pattern. We wanted it to ask me. This graph is exactly isomorphic to this graph. It just looks a bit shitter. The part-time is about some candidate daddy here who bought something I don't really care about, which is in the console category, where this candidate daddy bought something I don't particularly care about, which is in the category that is, and when this candidate daddy bought something I don't particularly care about in the category of beer. Why have I done that? Because if I found that out, I actually started to get something that looked a lot like Neo4j query language. In fact, if I had a match clause, it is now valid Neo4j query language. So the query has emerged from the graph structure. Now, I don't know much about simple databases, but in my experience of them, the query never emerges from the data structure. In fact, the query is an impeccable, novel level genius thing that someone has to do to make the query match the data structure. In graph, the query is naturally emerged because the data structure guides you. In this case, I'm now saying, in fact here's the full query, match where my candidate daddy bought something that's a member of the category beer, where the same candidate daddy bought something I don't particularly care about as a member of that is, and where daddy bought something which in this case is specifically in Xbox. Notice that the difference here is that there has not been a purchase of Xbox. Why? Because those people are the ones who's buying behaviour I could influence by printing them out of voucher, posting the voucher, or ever it may be. And return to daddy. For those of you who are a deep doctor, new fans, hereby dataset returns, Rory Williams, one of the doctor's companions. Let me handle it again. See if I was back on my own terms, there would be like a raptress of laws around it. Well done sir. Also good for near real time. Not hard real time. Do you not run a nuclear power plant on this? For near real time, in the kick-stream kind of applications that we build every day, when we build web-facing systems, graph databases are a great fit. They have that minutes to milliseconds kind of performance improvement that we're often looking for. And they're not just good for social. This is a now vastly outdated, obfuscated list of customers of Neo4j. And every time someone comes to me with something new, where I'm like, wait a minute, is that, oh yeah, that's a graph. Someone came to me and said, data centre management's like, well, yeah, because things are connected to each other that can be played within the rack. The rack's next to the switch. The switch next to the router. The router needs having initially time. Wow! An analysis of why we're at our data centre is blown up. Brilliant! Fantastic stuff. So they're really, really broad. They're not just for social stuff. Although they did probably get an early head start now. They're a very broad meeting. Now, free me. Two small fellows and me are for a book, for a writing book, graph databases. And it can come along to the Neo technology stand. So we're at Booth 29 in the exhibition area. We've got a copy for everyone. Some of them have had their e-base sale value reduced because my colleague has me to sign them. But some of them are pristine. So ask for a pristine one. It will be a fetch far more. If you go on Deadwood, if you visit graphdagebasic.com you can download the e-book for free as well. So please enjoy that book. And one more thing. If you like graph stuff, we're hosting the 2020 San Francisco Day for the Year. If you use the discount code DATIVERSITY who are the guys that run this conference, you'll get 50% off the Graph Connect app. So, thank you lovely folks for listening and laughing at the right places. It's been a joy to be with you. Go and hack all me about graph stuff any time you like. I'll be around one day.