Podcast Interview with Jonathan Schmidt, Waykonect

Here's another cool user story for you. I had a great chat with Jonathan Schmidt, founder and CTO of a great French startup called Waykonect that offers intelligent vehicle management based on Neo4j. They have been doing some really smart stuff and the use case seems like such a great fit for a graph - it's like a hand in glove. Listen to his story - it's very cool.


Here's the transcript of our conversation:

RVB: 00:00:01.221 Good morning, everyone. My name is Rik. Rik Van Bruggen from Neo4j. And here I am recording another Graphistania Neo4j podcast. And this morning I have got, well, someone not too far away from me on the other side of this call, and that's Jonathan Schmidt from WayKonect. Hello, Jonathan. 

JS: 00:00:23.314 Hello, Rik. 

RVB: 00:00:23.952 Hi. Thank you for joining me. 

JS: 00:00:26.779 Welcome. It's a pleasure to be here.
RVB: 00:00:28.886 Fantastic. Jonathan, we've been emailing back and forth, and you've been talking to me about your project with Neo4j, but most people probably don't know you, yet. So if you could perhaps introduce yourself a little bit. Who are you, and what do you do, and what's your relationship to the wonderful world of graphs? 

JS: 00:00:48.982 All right. Well, I'm Jonathan Schmidt. I'm CTO and cofounder of WayKonect. We are a fleet management company. Telematics fleet management. Our focus is data analysis, actionable intelligence from your vehicles, and we take a very driver-oriented approach to the field. Our belief is that you have to engage drivers if you want any kind of savings, any kind of actions to be successful on your fleet. So that's what we do. Analysing data and engaging drivers. 

RVB: 00:01:29.005 When you say fleet management that means lease cars or it means-- what is the fleet for you? Is it any kind of rolling material, or what is it? 

JS: 00:01:38.584 We mostly focus on small, light vehicles. So cars, mostly, small trucks, that kind of thing. 

RVB: 00:01:52.184 Okay. Very good. And then how does it work, and how does that work with the graph as well, potentially? Could you explain that to us? 

JS: 00:01:59.999 Sure. Well, we have telematics dongle that actually give back a lot of flow data about vehicles. And we use graphs to map the relationship between dongle, the vehicle, the account that manages the vehicle, the driver that drives the vehicle, the trips that are recorded, events that might happen on that trip, the maintenance of the vehicle. Basically, we use Neo4j as our metre graph for information. Everything that we collect from the data is stored and recorded in Neo4j in a graph style, which actually allows us to analyse it very quickly, very efficiently because we can link multiple things together, multiple items together, and get very interesting intelligence from it. And it also gives us flexibility to innovate, to improve over time because it's a NoSQL model. So when we need another kind of item to track down, when we need another kind of-- or should I say-- 

RVB: 00:03:16.511 A property or a relationship or whatever. 

JS: 00:03:17.789 A property, relationship, real-world object, a new feature that we want to track, we started checking and keeping track of maintenance for our vehicles. And that was just a new level, new relationships, and that's it. And from maintenance, came appointments, came markers on the map to-- so when was the appointment, where's located, came reviews on these repair shops, came-- and all of this just flows out naturally in the graph. And it gives us flexibility to improve, and the flexibility to analyse very efficiently. 

RVB: 00:04:02.049 Wow. That's really cool. So your model has been evolving a little bit as you had more requirements, agile development, those types of things? Is that what I'm hearing? 

JS: 00:04:11.271 Indeed. Indeed. It's evolving constantly and basically every month or every two months we add one, two new labels to the graph, new relationships and new way to actually get insight from the data. 

RVB: 00:04:24.217 Wow. Cool. And are there any other data components to your application that you're using? Analytical components or other database stores, or is it mostly Neo4j? 

JS: 00:04:36.157 Neo4j is our metadata store, so everything we get out from the data is new. For the raw data itself, we actually use InfluxDB as a time series repository. And we are also using Kafka as a messaging backbone for the whole infrastructure and so that all of our services can analyse the data as it comes in. 

RVB: 00:05:04.584 Yeah. That's sounds like a great idea. Great architecture. So can you talk to us a little bit about how you got to Neo4j and why you started using a graph for this? What's the main advantage to it for you? 

JS: 00:05:18.219 Well, our first proof of concept was obviously [laughter] built on SQL. That panned out good for a few vehicles, for the 100 or so vehicles we had in the test, and but my belief was that it was untenable at scale, storing telemetries, storing raw data, and the metadata in SQL was going to be a nightmare whenever joints would be involved. And I mean, whenever you want a trip, you have to join the accounts that the vehicle belongs to, the vehicle itself, the trip, some events that might be off-scoring but may be related to it, and it's three, four, five-part joints on every request. And that would quickly become problematic. And when I started devising our data model, I had an engineer with me who said, "Actually, this makes me think of graphs and maybe we should check out the field of graph databases." And it basically started this way. We checked a few graph databases, settled on Neo, because it seemed to be the best fit for architecture and in terms of maturity, in terms of functionality. And we did a first proof of concept with the new project client in C# because our whole architecture's on .NET and it was just so easy. You create a class, you put in properties, and you can [inaudible] in one message, and relationships comes at almost no additional costs. 

RVB: 00:07:19.950 That's fantastic to hear. I mean, it sounds like a great [crosstalk]. 

JS: 00:07:23.237 Yeah. It was just so easy, so fitting, it stuck. And it's a choice I've never ever regretted making. Our transition to Neo4j was, I believe today, one of the best decision we ever made. 

RVB: 00:07:43.778 Wow. There must be something wrong with it [laughter]. 

JS: 00:07:47.867 Well, we had a few, of course, there was a few problems along the way, but mostly it came from our data model. We had a few issues with transactions and HAProxy because we are on an enterprise high-availability cluster. So routing transaction correctly from slave to master or keeping a transaction on the same server is a bit of challenge sometimes. But other than that most of our troubles was because we didn't understand technology at first and we actually built it as we learned. And we've made a few mistakes in model along the way and it was actually incredibly easy to smooth them out at a later time to refactor the graph. And that was also something that clenched it for me. I mean, you identify and isolate the problem, you refactor in one or two codes and a few change in your code and that's it, problem solved. That's just so easy. 

RVB: 00:09:07.273 Excellent. Well, that was kind of the past, right? So what does the future look like? How do you plan to use it in the future? How do you plan to evolve your application and also maybe any perspectives on what the industry is going to be doing on this? 

JS: 00:09:28.361 Well, as for us, my next step is [inaudible] clustering and I'm just a few steps away from having it work correctly [laughter]. Currently having a bit of dependency problems with dot net. But [laughter] that's something that should be easily solved and [crosstalk]. 

RVB: 00:09:50.075 I hope so. Otherwise, you know where to find us, right [laughter]?
JS: 00:09:52.654 Exactly. And I think [inaudible] clustering will be the next big step and what will take us from really scalable to infinitely scalable [laughter], I guess. As far as the industry, well, it's a bit-- as much as you-- when you start using graph databases, you start seeing application for them everywhere. Even up to research in ancient languages. You can probably index and cross-reference hundreds of texts in minutes or hours just because you can actually cross-reference words and phrase from it. And the language doesn't matter as long as you have a [unique alphabet?] for it. And this is so powerful and it's just one application off the top of my head because I double in that on the side. But-- 

RVB: 00:11:00.404 Graphs are everywhere, right? 

JS: 00:11:01.883 Graphs are everywhere.
RVB: 00:11:02.063 Once [laughter] you start getting into the mindset you start to see them everywhere and that's so fascinating. 

JS: 00:11:10.033 And you start to see also what good they could do. You have so many people building complicated software just to solve graph-related question that could be solved in a few Cypher queries and at the time port, so. 

RVB: 00:11:28.278 Couldn't agree more, Jonathan. I think we're on the same page there. Absolutely. Thank you for sharing your experience with us. I think that was super nice and super useful for lots of people. We'll put some links to your company and your experience in the transcription of the podcast. But for now, this is I guess where we're going to be wrapping up. Thank you so much for coming online, really appreciate it. And I look forward to meeting you soon sometime. 

JS: 00:11:58.764 You're welcome. It was a pleasure. And please, feel free to drop by just give me a holler one point. And, yeah, we can meet definitely. 

RVB: 00:12:07.894 Fantastic. Thank you, Jonathan. Have a nice day. 

JS: 00:12:10.741 Have a nice day. And thank you, Rik. 

RVB: 00:12:12.138 Bye.

Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!

All the best

Rik

Podcast Interview with our Fearless Leader, Emil Eifrem

Well, today most certainly is a high-point in my podcast experience so far. A couple of weeks ago I got our lovely co-founder and CEO Emil Eifrem (I spoke to the other two founders - Johan and Peter - before) on a Skype call, and we chatted away - and even did a Pop Quiz including a HIGH QUALITY DRUM ROLL! YES!

It was a wonderful chat, I think. Spontaneous and right from the heart - you should not miss it.


Here's the transcript of our conversation:

RVB: 00:02 Hello everyone. My name is Rik Van Bruggen from Neo Technology, and here I am again doing a podcast recording that I've been looking forward to for a very long time with my Über boss and CEO [chuckle] Emil Eifrem. Hi, Emil.

EE:  00:19 Hey, Rik. How's it going?

RVB: 00:20 It's going really well. Thank you for coming on the podcast. You're number 33. I think there must be some symbolism in here.

EE:  00:27 Anytime you describe me as an Über boss is a good time in my day.

RVB: 00:33 Absolutely. Emil, thanks for coming on the podcast. Like always, we're going to ask you some questions and talk a little bit about graphs and Neo4j, obviously. And we've got a little quiz prepared, so that should be interesting. First of all Emil, many people will know you, but not everyone. Could you introduce yourself? Say who are you, what do you do and what's your relationship to graphs and Neo4j.

EE:  01:01 Sure. I have been here since the beginning together with my co-founder Johan and my co-founder Peter back in the late '90s - in '99 and early 2000s. We got the idea that maybe we could structure data in a different way. And we got there through a variety of reasons and means, ran into a couple of problems that were ill-modeled - difficult to model in a relational database. So, we figured that there's got to be a better way. Eventually, through a number of complications and a very non-linear path, ended up with what's today known as the Property Graph Model. That was quite along time ago and it was at a different startup. I was the CTO of that startup and didn't start it or anything, but I was the CTO. Since then, I've basically been working on graph databases. And back in 2007, we spun out the IP from that old company and formed what today is Neo Technology.

RVB: 02:12 That has been quite a ride, hasn't it? It's quite a long time, actually, if you think about it.

EE:  02:19 Yeah. One way of looking at it is that this is all I've done my entire professional life. I've always been working on graphs, professionally. I, of course, grew up as a hacker way earlier than that. I have worked in a lot of other software, as well. But really, my professional focus for the past 15 years has being on graph databases.

RVB: 02:42 Amazing. The question I always ask people on this podcast is also, "Why? Why graph? What's so good about graphs?" What's your perspective on that? I'm sure you have a couple to share.

EE:  02:56 Yeah. This is easily a topic that could fill many podcasts for me. But I think, fundamentally, it's because that's the way to make sense to the world. That's the way that the world makes sense to me, fundamentally. As an individual, I don't know if you would agree with this - describing me as your Über boss - but I'm a very relationship-oriented person, and I just think that's sort of on a human level. But I also think that's just how computer systems and how software fits together. And I think that there's a lot of value in being able to explicitly declare and honor relationships and data, and that's fundamentally what the Property Graph Model is about. There are some number of benefits, but if you peel away everything, it really all stems from the fact that relationships are first class citizens. And I think that's how I look at the world, and that's how we ended up with that model.

RVB: 04:05 Absolutely. It's kind of interesting to me when I talk to users or prospects about this, we always compare it to the relational model. And I always say, "You know, the relational model is very anti-relational." You know ?

EE:  04:18 Yeah.

RVB: 04:19 It isn't that relational.

EE:  04:21 It's weird because the word "relational" is actually from mathematical relations not from the relationship, but that's too fine of a distinction. Most people around don't know that and it's kind of hard to communicate, but it is funny that graph databases are way more relationship-oriented than relational database, which on the other hand is way more relationship-oriented than most so-called NoSQL models out there, than the key-value model, or document databases, et cetera.

RVB: 04:50 Very, very true. Absolutely. This could go on for a very long time, but instead of doing that--

EE:  04:56 No. Come on [laughter].

RVB: 04:58 Instead of doing that, I thought we would do something different for this podcast, after all you are the Über boss. So I thought we'd do a little quiz, if you're up for that.

EE:  05:09 Let's go for it.

RVB: 05:10 Let's go for it. The quiz is very simple. I'm going to give you two words, and you're supposed to pick a word and tell me why you're picking the word. Is that okay?

EE:  05:22 That is okay, but only if there's a dramatic way of introducing the question. Like, for example, a high quality drum roll.

RVB: 05:32 Like for example [music]. Was that what you had in mind?

EE:  05:38 When I think high quality drum roll, that's exactly what I had in mind [chuckles].

RVB: 05:43 All right. We'll start with that. The first two words are very, very easy to get you going. What do you choose between sports or music?

EE:  05:51 Definitely music. Definitely music. It's funny. Now that I live in the US, then there's all kinds of sports analogies happening here in business. I think the only rival source for analogies in business is military. Everyone goes to military analogies, right? But then the second one is always sports, and it's about this filling the stadium over there, it's getting to home base over there, and it's third - it's like all of these kinds of sports analogies, of which I know absolutely none. Then of course, after that, people then assume that it's because I'm European. So then they go to soccer analogies instead, and I have no idea about those either. So sports has never been my strength--

RVB: 06:44 But what about music?

EE:  06:45 Absolute utter geek in that respect. Definitely music. I've, on the other hand, always dabbled in music. In fact, I'm actually a classically trained pianist, which I sometimes use. For example, when I give some talks about Neo4j, whenever I mention the word relational database, at a couple of events, there's been a piano in the room, for whatever reason, and then I walk up there and I play, "Dum, dum, dum, dadum, padum." You know the Imperial March, right?  So it even comes to good use in my modern day present role. Now, I think music has been a very constant in my life, whereas sport hasn't. So it's an easy choice for this one.

RVB: 07:33 Absolutely. I think it's time for a second question, if you're up for that.

EE:  07:36 Go for it.

RVB: 07:38 Here we go. [music] High quality drum roll for you. And the question is, USA or Sweden?

EE:  07:49 USA or Sweden. I'm going to have to go with Sweden there, and it's funny. This is the second time in my life that I live in the US, and I'm the least nationalistic person that you'll ever find, in general. However, I've observed in myself that the moment that I move outside of Sweden, is the moment that I really start loving Sweden. When I lived in Sweden, I criticized it all the time - with all these things that are broken, wrong, and fundamentally flawed, et cetera. Except, some magical, the moment I get on that plane and I land somewhere else, it is this absolutely perfect Utopian place that can never do anything wrong [chuckles]. And since I am in Silicon Valley as we record this, I'm definitely going to choose Sweden.

RVB: 08:34 Absolutely. How does that relate to things like corporate culture and stuff like that? How would you describe Neo Technology in the corporate culture?

EE:  08:44 That's a great question. As you well know, Rik, I rant all the time about this. I have the saying, "I want to create an American company with a Swedish soul," right?

RVB: 08:55 I wanted to hear you say it [laughter].

EE:  08:58 It's kind of a weird expression, but it means something to me. Basically, growing up in Sweden, I grew up very much to the left of most people in terms of politics, and not just-- here in the US, of course, there are like one extremely right-wing party, and then there is the Republicans to the right of them, right? From that perspective, then every single party is left. But even in Sweden,  like I grew up in the left wing. Then amongst that group of people, its not very common to - how should I say this - big American companies aren't usually the most idolized organizations on the planet. But despite that, I've actually always had a big admiration for big American companies. And yes, there are so many things that are fundamentally flawed about them, but the numbers speak for themselves. If you look into  the Fortune 500, there is a huge, huge disproportion to many of them that are American companies, and they're just very, very good at executing in many-- very good at execution, I should say, in many instances. I admire their aggressiveness, I admire their ambition - the fact that they set goals and they measure themselves to them.

EE:  10:17 On the other hand, I think there's a number of things where American companies, in general - I'm stereotyping now - where American companies don't act in a way that I can agree with, and primarily around how you treat employees, how you treat your fellow colleagues. And that's why I think that Swedish companies, who aren't the most amazing on the planet when it comes to setting aggressive goals, for example, but they do excel, I think, in terms of creating a culture where you have truly individual peers that, in general, treat each other very respectfully and very well, and have a more humane approach. And I want to marry the two of them into one company. So that's why I say that, "Building an American company with Swedish soul."

RVB: 11:01 I'm going to have a quick drum roll [chuckles]

and I'm going to ask another question [music] that is very related, I think, which is authority or consensus?

EE:  11:13 Authority or consensus. Definitely consensus. I'm a very consensus-oriented person. I think that consensus is one of those words that people tend to have a very negative view of that word, and sometimes for good reason because it can lead to some bad things. There are definitely bad forms of consensus that lead to, basically, from a technologies' perspective and a database' perspective that lead to deadlocks. If you end up in a situation where you, as an organization, you can't execute until everyone buys in, then that's not good because it doesn't scale. But it is incredibly powerful that if you have a small team that has set out to perform a specific task or reach a specific goal, if that small team has achieved consensus around the approach and the method through which they're going to get there, that unlocks what I believe is one of the most amazing powerful forces on the planet, which is intrinsic motivation. That's how you get really smart people to be motivated is giving them an opportunity to chime in, and through discussion, arrive at their method of getting there, and then they feel ownership. And consensus is one way of getting there. But it has to have controls in place where it doesn't lead to deadlock, and that's an important one. But between consensus and authority, I definitely choose consensus.

RVB: 12:50 I've been with Neo for about three years now and I've definitely seen you actively promoting it, so I really respect that a lot. Cool. I think we need another drum roll.

EE:  13:05 I was just waiting. [music] What is that? Is that from your cellphone or something?

RVB: 13:12 Yes, it is. Yes, yes [chuckles].

EE:  13:15 It's great, very high quality.

RVB: 13:17 You row with the means that you have, right [chuckles]? Lead or follow?

EE:  13:26 Definitely lead. I don't know if anyone else would-- this may not pass the “not” test. You want to choose words where everyone would not choose one of them, and I think most people would choose lead here. But I'm still going to go with the flock and choose lead, ironically enough. I think that's one of the things that I do believe that we do here at Neo Technology. I think that graph databases as a category didn't exist before we got started, and I think that we've done a lot of work on not just promoting Neo4j, this specific product, but graph databases and the general approach. And I think that part is one aspect where I'm actually proud in how we've led the industry, not just for our own benefit but truly because we believe that the general approach of having a relationship perspective on data is valuable.

RVB: 14:23 Absolutely. It comes with a lot of costs as well, right? Leading is expensive, isn't it?

EE:  14:30 Yes, that's very true. And I think there's just from whatever business strategy perspective, I think there's a lot of examples where you have a so-called first mover in an industry that takes a lot of cost, and effort, and blood, sweat, and tears to build momentum around something, and then the so-called fast follower comes in and swoops it away. In many ways, I think, that's exactly where we are in the graph space right now. I think that certainly 15 years ago when we got started, but even two, three years ago. For example when you started, I think it was much less obvious that there would be a distinct, stand-alone, huge category called graph databases. We all believed it, right? We all kind of saw it, but I don't think in general that if you would ask 100 database experts, that they would agree with that. I do think that is true today.

EE:  15:30 So, we are now exactly at that point where the category as a whole is about to take off, and we see it in the competitive landscape, as well. We see that there's a bunch of big companies that used to ignore graph databases and talk about it as a niche, but we now know are building out proper, full blood property graph implementations, and take them to the market. So it's a very interesting time in the graph database space right now.

RVB: 15:57 Very true. One more, okay?

EE:  16:00 Sure. Go for it.

RVB: 16:02 [music] I'm going to use this in presentations [laughter].

EE:  16:08 Of course, I mean it's just that good.

RVB: 16:11 It's so good. Focus or platform?

EE:  16:15 Focus or platform. Wow. That's a hard one because I want to choose both of them. But if I have to choose, it's going to be focus because I think that you build out a platform through a focused product. Because a focused product is what ultimately delivers the most value to users. And I always had this - I don't know what you call it if it's a motto, a mantra, or something. But when I was very heavily involved with designing the product, which unfortunately or maybe fortunately I no longer have the bandwidth to do, but I always had this saying where it's like, "When in doubt, leave it out." Whenever I or we had any kind of concerns like, "Is this feature truly needed by everyone?" We would leave it out, because I think that all great things, all great products out there that at that least I admire have a strict focus to them. And I think that's how you get broad adoption, and from there, you can then build out laterally in the product, which ultimately will create a platform.  So if I have to choose, I'm going to go with focus.

RVB: 17:36 It's sort of also makes me think, at least, and part of the reason why I asked the question is the “Crossing the Chasm” analogy of [?] [more?]. Okay, very cool. I think we are going to wrap up here. It's almost 20 minutes into the podcast so--

EE:  17:53 Time flies when you are having fun.

RVB: 17:56 It does. It really does. I want to thank you again for coming on the podcast. I think all of the listeners will really appreciate it, as well. And thank you also for building a great company and a great product together with all of us.

EE:  18:09 Together with many people and very much including yourself, Rik. This podcast, I was just mentioning this to Rik -- for the listeners, I was mentioning this to Rik before we got started that I don't think I listen to every single episode. There may be one or two that I have not listened to, but I'm biggest fan of this podcast. I think it's a treasure trove of how people thought about graph database, and I think we're going to look back on it ten years from now and just hear voices actually from the source at the early beginning of this amazing category.

RVB: 18:43 I hope so, too. Thank you again and I look forward to seeing you and meeting you again very, very soon.

EE:  18:49 Thanks, Rik.

RVB: 18:50 Bye.

EE:  18:51 Bye bye.

Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!

All the best

Rik

Podcast Interview with Peter Neubauer, Mapillary (and co-founder of Neo4j)

Today is a special podcast episode. I got a chance to talk to one of Neo4j's founders, Peter Neubauer, again - which is always fun. I remember one of the first conversations I had with Peter, where he was explaining something to me over a skype call - and he was at the same time pushing a core Neo4j bugfix to github. Just to say that he is pretty awesome and incredible at multi-tasking :)) ... Peter left Neo last year as an active team-member, to start a new project that "looks just as impossible", Mapillary. Take a look at it for sure - but listen to the podcast first:


And here's the transcription of the chat:

RVB: Good morning everyone. My name is Rik, Rik Van Bruggen, from Neo Technology, and here we are again recording a remote session for our graph database podcast. I'm joined today from Sweden. Peter Neubauer is on the other side of the line. Hi, Peter 

PN: Hi, Rik. Nice to meet you. 

RVB: Yes, good to be on the phone with you again. It's been a while. Peter, if you don't mind - most people will know you - but, would you mind introducing yourself a little bit for people that don't know you yet? 

PN: Yes. Regarding Neo4j, I'm one of the three founders of Neo4j together with Emil and Johan who are currently working on Neo Technology. Actually, it was us three who came up with the first version back in 2002 and wrote the first version that went into production. 

RVB: That's a long time to go, huh? 

PN: That's long time ago, yes - 13 years. 

RVB: Absolutely. It's been quite a ride. How did it start Peter? How did you guys get into Neo and where did it come from? 

PN: It did start with us having written or gone into content management systems. And we are at that point managing images, and one of the major problems there was that every photographer, every picture agency, had their own rights management for when the image could be licensed as to whom, in which country, and so on, so there wasn't a lot of business logic about that. Modelling that in, what then was, Informix, and it was a server, our database that was one of the most capable database engines at the time - and object relational database engine-- 

RVB: Didn't they get acquired by IBM, Informix? They did, right? 

PN: Yes, they did. And this was the last version, 9.14, that came out before they were acquired. And we were trying to model our business logic in that engine and it just didn't scale. We got into like five, six joins, and even with the, at the time, modest data in that database, it was just taking ages, like minutes, to get answers back, and that's not good enough for a backend that needs to surf on the web. At that point, we examined our system architecture and found out that the database was the bottleneck. And we also at that point had some of the Datablades or plugins to Informix, and one of them was dealing with the semantic words for translation, namely WordNet, a semantic initiative to structure the English language. And that kind of projected in network model off these connected words, like hyponyms and synonyms and concepts into the database. And we saw that and thought like, "This is a very interesting approach to model data." It's very close to the UML diagrams and so on, if you translate it to our domain. We tested that plugin for our domain just to see if the model fit, and it did. However, it was still slow, so since it was such a beautiful match, we then went about and actually wrote, at that point, a Java Enterprise JavaBeans, 1.0 implementation that modeled that kind of structure what is now-- and that actually had the first kind of Java version of what is now the Neo4j API, all these fleshed out. 

RVB: Did you call it a graph API at the time, or do you call [crosstalk]? 

PN: No, no, no. 

RVB: What did you call it at the time? 

PN: We called it a network database or network engine, and that's where Neo partly comes from. Of course, the matrix is very popular but it also stands for network engine of course, so we had to make it work [laughter]. 

RVB: Fantastic, okay. I don't know if I've ever told you that, but one of the projects that I've first worked on was a project for DHL which was also using Informix Datablades. 

PN: It was a very good database. 

RVB: Super. Where are you now, Peter? What are you doing now? You're working for a new startup, right, Mapillary? 

PN: Yes. I left Neo Technology last year, mostly because I found-- I'm and early startup guy and Neo4j has a big group of followers now and there's so much activity around it so my feeling was that I can't invest my time in something that is, again, almost impossible, so I joined Mapillary as a co-founder and the vision there is to do a visual representation of the whole earth possibly even a 3D model connected to it. So that's what we're doing. People are submitting basically thousands and thousands of images taken by their smartphones or action cameras and so. And we in the background do a lot of computer vision and analytics on this data and we connect the images into what could be described a big, global, giant graph of visual information. So Neo4j is an essential part of  the architecture there. 

RVB: Oh, is it? What do you use it for? What do you use Neo for? 

PN: We use it for connecting the analyzed images both in space for instance so you have actually this connection between one image and the nearest images in different directions, and then even connect computed visual connections. For instance, one image overlapping another image so if two images look at the same view of the turning torso, then we will know it and we will actually create a connection in that image graph in-- from this image, you can translate the object, turning torso, into something that can merge into the others, so we know how to project and we even store the 3D point cloud of these objects in Neo4j [inaudible] references too in Neo4j. The whole navigational logic, if you then want to construct, for instance, a street view from these millions of images, it's done in Neo4j but because it's a perfect use case for Neo4j. Basically fetch all the connected images in the vicinity of say a connected images that 3 or 4 or 30 if you are going to fast forward then prefetch these into a local graph in JavaScript and do that along certain rules while you are traversing the backend graph. For instance, time filtering, or filtering just certain color, shades, or certain directions or what not. 

RVB: Super. That's really interesting. I think people can get involved with the Mapillary project as well, right? There's like an app that they can download and then you can participate in the project, right? 

PN: Yes. Anyone can submit pictures and anyone can help improve the data. It's like OpenStreetMap of Wikipedia, so you can improve even, for instance, street sign detections and object detections that we do in the images and feedback to for instance the OpenStreetMap project and to Wikimedia. 

RVB: Cool. Peter, maybe one more question because we keep these podcasts quite snappy. Where is this going? Where is Mapillary going? Where are graphs going? Any vision on that? Do you mind sharing that? 

PN: I think the concept of connected data is growing a lot and people are expecting and willing to put in much more effort into making data connected. That is not just on the global linked data initiative level, but even on pragmatic in-system level. So where I see graphs going is that they approach enterprise. Enterprise Connected data are even in normal installations, and as we see it here with a lot of developments in virtualizing hardware and so, you can partly build bigger monolithic kind of graph blobs. In Mapillary we have now over 1 billion properties in the database within one year, and that is one thing. The hardware is letting you scaling up these installations quite a lot, so you can scale up quite easily. And the other thing is that sharding graphs will be the forefront of data science. That is one of the remaining kind of challenges with graphs. They're very easy to query and so on, but sharding them is not trivial. 

RVB: So difficult. Yeah, yeah. 

PN: It's difficult, yeah. 

RVB: I'm sure you've heard of the work that Jim Webber and Co have been doing on that, and we are really in the middle of starting that project again and making some good progress there. 

PN: Yeah, I'm really excited about it. Right now, in Mapillary, we will go for bounded boxes and shard by geography, and if you have a domain that lets you [shard?] it in a kind of interesting way, then you can do this already now, but auto-sharding would be awesome. 

RVB: Super. Peter, thank you so much for coming on the podcast. It was pleasure to talk to you again. I really appreciate it. I wish you so much luck and pleasure and drive at Mapillary, and thanks again. I look forward to speaking to you soon. 

PN: No problem. Nice to talk to you too, Rik. 

RVB: Cheers.

Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!

All the best

Rik