 Welcome, my name is Shannon Kemp and I am the Executive Editor of DataVersity. We would like to thank you for joining today's DataVersity webinar, Hot Topics and Graph Databases. Due to a large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A section in the bottom right-hand corner of your screen. Or if you would like to tweet, we encourage you to share highlights or questions by Twitter using hashtag DataVersity. Next, 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. Today is an elite panel of specializing in Graph Databases, Leon Guzendas, founder of Objectivity and Infinite Graph, Emile Efrem, CEO of Neo Technology and Neo4j, and Andrea Lopez, Senior Director of Spatial and Graph Technologies from Oracle. This is a theme panel as DataVersity's partner in the NoSQL Now conference in Expo, Dan McCrary. Dan is an enterprise data architect and author specializing in emerging database technologies. He has worked at BABS with Steve Jobs at Nex Computers, as well as founding his own consulting firm for over 75 people. His background includes topics such as high-performance computing, programming languages, databases, and XML standards. He has published articles on the Semantic Web, metadata registries, U.S. federal XML standards, X-Forms, X-Query, and XRX. He is the author of the book Making Sense of NoSQL by Manning Publications. With that, I will give the floor to Dan to start the discussion and introduce our panelists. Well, and welcome. Thank you very much. I'm really excited to be here today. I think we have a great panel and a great topic here. There's something about graph databases that are inherently appealing to me and a lot of the problems that I deal with in information management. And I'd really like to have our speakers start out with a quick introduction of yourself, the company that you're with, and maybe a quick background of what got you into graph databases. Linda, can you give us a start here? Sure. Thanks very much, Dan. Well, I've been in databases practically since the beginning of the technology and was for a very long time a program manager on large projects around the world. I'm first going to go back into the 1970s, dealing with data for NATO and for the Joint Intelligence Headquarters in London working with us. When we found projectivity, we set out to solve problems where there was very high interconnectivity in the data. And that's really been our focus for the last 25 years. We produced the infinite graph about three years ago because the technology was becoming more visible to the community if you like. And that's really the kind of customer base that we've had rather than just being over in the telecom and process control equipment and the intelligence community isn't going right across the board. And I think that's a very encouraging sign. Thank you very much. Any thoughts about yourself? Thank you, Dan. And thank you to DataVersion for hosting this use call it esteemed panel. It's a pleasure to be here. My focus, graph databases, it's been the focus of my professional life. I do not have as long of a professional life as my friend and colleague in the industry, Leon. But I've been at DataVersion for around 13 years. Back in 2000, I worked at a small enterprise content management start-up here in Sweden. I'm in Sweden right now, normally based in the Bay Area. And we ran into a bunch of problems. We had built our stack on the sort of traditional, at the time, stacks. We had a middle layer which was like EES or J2EES. It was called and a web front end and whatnot. And then of course, in the data layer, we had relational databases. And we worked with the usual culprits. We worked with Informix and DB2 and work and whatnot. And I had 20 engineers. I was the CTO of this small start-up. And half of my guys spent the majority of their time just fighting with the relational database. And I, for the world, couldn't figure out why. So I didn't think that we did anything too complex on the data side. It turned out that when I started double-clicking on that, that we actually did. It turns out that we had a lot of connect data, big file system trees, as well as lots of big user hierarchies and security models and things like that. And that turned out to be really, really hairy to model in a relational database. Once you got through that point, when you were able to model it, it performed really, really poorly. And so we Googled a lot of things. We added this around or Yahoo'd around. It was early 2000s, right? For a database that could natively speak, connect the data or graphs as we later on learned. And it couldn't find anything. And this is at a point in life when I was young enough and naive enough that when I got a good technical idea, I said, screw it, let's build it. Which, truth to be told, is a stupid idea. All things being equal, you don't want to build your own database. But we didn't know that at the time. And we really needed something like this. So we came out and we built it. And on a flight to Bombay in 2000, I sketched out the initial model. Actually on a napkin, stereotypically enough. The model that is now called the property graph model. We implemented that and wrote a couple of prototypes and what we then put in production in 2003 is what is today called Neo4j. Which is a graph database that implements the property graph model. And we formed a company around it in, I believe, 07. Which is the commercial sponsor. But the software in office completely opens doors. Neo4j.org. So that's me in a nutshell. Thank you very much, Emil. Right here. Tell us about yourself. What drove you into this wonderful world of graph technologies? Well, everybody, I've been with Oracle for about 15 years. And so that whole time I've been involved in spatial technologies, dealing with more with mapping digital and geospatial stuff. So I've been focusing on managing geospatial data in the database. But one type of geospatial is graphs or networks. So they're commonly referred to as a net space. And so managing networks for roads, electrical networks. And then not only just managing these large networks, but it might represent, say, all the roads of Western Europe and North America, managing them scalably. But also doing performing analysis, path analysis on that. And so we introduced the first graph database for that kind of networks in the Oracle database years ago on that. And then after the semantic web technologies came up and social media started to emerge. And so we did the same thing for that. Essentially managed triples of the, essentially, the W3C's RDS graph model, which is in the form of triples. So essentially extended the Oracle database to manage RDS triples and then be able to perform inferencing in the database. So basically addressing the problem or the problem was basically extending standard relational technology to have graphs more natively on that. But more recently, I've been involved in essentially doing the same thing for providing graphs capability to Oracle's NoSQL database or have that NoSQL database in addition to relational databases. And so our task, or at least our team's task, is not only to make sure that spatial content and co-processing is native to our database families, but also to for graphs as well. So that's where I come from, really straddled both sides on the spatial one graph. Great, that's a good overview. I forgot to mention at the beginning that we usually go about 40, 45 minutes with a discussion. Then we open it up to questions from everybody. So I just want to remind everybody that you can use the WebEx software and there's a special panel for questions. So feel free to, as we're discussing these things, add your questions to that. And if we cover them in the discussion we're starting here, we'll try to get back to them towards the end. I have a couple of questions I'd like each of you guys to answer. I'm just incredibly surprised at the continuing growing interest in graph databases. When we first started this conference, we thought that graphs were going to be kind of a side thing and it wasn't going to be front and center. But in this conference we seem to have more graphs of vendors and more interest in graphs than a lot of the other types of NoSQL data stores. So, Leigh-Anne, when you start this out, tell us why you think graphs are becoming so popular now. They've also been popular in the background, but it's been a quiet movement if you like. And I think over in the social networking world there's really a lot of things to look for. And I give credit here to me and the open community for coming in on this problem as well and starting to do more and more work in this area. So, the theory course has been around for 300 years, but more and more people aren't getting interested in it. And the general movement in general has helped that as well. So, the blinkers come off and people aren't looking for a single solution anymore. They're prepared to look at different kind of database for different parts of the problem. Yes, I totally agree. I think that technical movement has almost given people our permission to look outside just the narrow field of relational and analytical databases. So, that really makes sense from what we're seeing. Do you have any thoughts on this topic of why we're seeing so much interest in the last couple of years? Well, I think you mentioned a couple of things. There's the broad industry trend of looking beyond the relational database. People have called it NoSQL, not only SQL, or they've probably polyglot persistence and lots of different names. None of the names really is a great name, but particularly the concept, of course, is that we're part of the point where you can just block and take your dataset and just assume that it will always work great as a relational database, which has been actually true for the amount of, at least, you know, part of the time that I've observed the industry. You know, back in the 90s, when I grew up as a professional programmer, the choice was not really what type of database are you using or what data model does your database have. The choice was a vendor choice, right? Should I go with, you know, Microsoft SQL Server later on, right, but initially Oracle or database or, you know, DB2, it was a vendor choice, it was a vendor choice of the type of database. And the nature of information has changed since then, right? We've obviously begun another phantom that I love to hate, but, you know, it has some form of, you know, data volumes are growing rapidly, right? So that's one aspect. But also the fact that data is becoming increasingly connected, or at least that people are seeing more and more places where they can unlock a lot of value by looking at how data is connected. And that's just a really, really poor fit with the relational model because it inevitably leads to a bunch of joins. And that's just not performing well and doesn't have a very convenient program model. So these three things really connect, I think is the main reason why that is happening right now. Yeah, I agree. That's a very interesting insight that the more data we have, the more connected we potentially have and having a tool that we can connect heterogeneous databases that weren't designed to work with each other, that technology has become more important. David, do you have any perspectives that you'd like to add on this? The point is critical within enterprises, and that's why our customers move toward the graph feature is essentially to treat, typically create an enterprise standard, standards-based meta-graph model. It has to be a graph form. I'm referring to the RDF graph model. It has a standard for the model, the definition of the model. It has a standard for the query. But most importantly, it's flowing from the get-go by a W3C to essentially program this linked layer to manage the integration of relational databases, the system-relational databases, content management stores, big data stores, streaming data and so forth. And that's the challenge of today, is essentially how do you integrate all of these different data types as some folks refer to it as big data. But then the integration problem is huge. It was a big challenge when you just had really big databases integrating the scheme as you had all these semantic issues and doing that. But RDF, a graph model in particular, is ideally suited for this integration capability. So that integration problem has grown as different data types coming in, but also because different application developers don't want to be coding to the underlying data models. So they'd rather be coding to a semantic layer that more evenly reflects their dynamic of the vocabularies. And so this graph model provides that semantic layer that makes that possible. Okay. Let me change the order up a little bit. I'm going to all reverse it here and ask Xavier the first to respond to this next question here. What kind of vertical industries are you seeing that are the earliest adopters of graph databases? We obviously know the social networking space is using graph databases quite a bit. Are there other vertical industries that you're seeing or are picking this up before others? Before we get into that, I think it's important, and we may not have the time to get into it in this call, but unfortunately, there are different graph data models. And they're essentially designed, or they have sweet spots to address certain different problems, whether it's a debugging problem or an analytical problem. And so that's important to understand is that the different graph models are there. And which model is best suited to the form of an application to address that area. So for example, in the telecommunication space and transportation space, there's a network graph model. And it's essentially a node model. You can apply constraints to the links of the nodes and influence the path calculations. So if you use Google Maps, Google Earth, or Google Maps to do driving directions, name your favorite routing application, it's a built-in graph model. And it's essentially designed for very fast path calculations, one to many, traveling salesmen, all these different types of network calculations that have been around as Leon says for a few years. So those algorithms now exist on these models. There's the W3C already a graph model, which is essentially designed for integration to integrate different schemas and layers. And this is used a lot by businesses that are trying to integrate different, either distributed or federated resources to create these outputs known as logical data warehouse where you have the representations in the form of schema and resources on that. And then the third category, as Leon was referring to, is this property graph model as well to support other ranges of applications. So each of these three, and there's more than that, have a sweet spot that they address, and I think it's important to understand what they're best suited for and then which implementation of them would make the most sense. That makes sense. Next, do you have any comments on vertical industries that are using Neo4j today? I actually have some comments on Saviour's comments as well, but let me quickly read in with the answer to your question first, Dan. So we have a lot of people who are actually horizontally across the field in terms of verticals. There's a bunch of verticals where people are experimenting with graph databases, with expanding connected data, let's say. But primary ones where we've seen early adopter traction, where they really have recently moved from experimenting to actually deploying it in production in mission-critical situations is telecom, as was mentioned before. Finance, we have a lot of up-taking finance. We have a lot of interest from healthcare, which surprised me actually because it tends to be usually longer adoption cycles in healthcare. But that has been a very recent, just this year for us. We probably have tens, if not 20, of reduction deployments in healthcare from like three or four second half of last year. So there's a lot of traction in healthcare. And then gaming, gaming is picking up steam really, really rapidly with us. So those, I'd say, would be top ones. But we have a bunch of deployments as well outside of that. I mean, one of the most critical logistics deployments in the world was done in Europe, packaged for routing for a major country in Europe and it was all based on Neo4j. And so we see that kind of action as well outside of the core. But if I could mention a few, those three are the ones. All right. How are you doing? Do you have any specific virtual interviews that you're following and are getting a lot more uptake? Yes. We have a steady background in the intelligence community, telecom networks, cyber security and finance. Over the years it's been very strong. Great news in North America, for instance, to consolidate all the data from their client base overnight and send it back to them. But recently you've seen an upswing in healthcare, logistics, agriculture and retail, tracking seed to consume kind of stuff. And if you look at the trend, have you tried to lump it all together? I guess people are exploring metadata in more powerful ways. That's the trend. They're pulling some data out of existing databases and using our technology to explore the metadata. Interesting. Okay. That's great. I'll just throw it out to any order here if anybody wants to jump in. One of the things I really love about our NoSQL conferences is that people come to the conference with real-world stories of times that they've tried to use in a relational database or maybe the wrong database. And then we assembled the right database and the job just became orders and orders of magnitude easier. And I wanted to invite any of you three to share any recent stories you guys have about case studies of people that were struggling trying to do it with one type of used-to-graph database and made their problems easier. Anybody want to jump in? Thank you, dear. Pharmaceutical company, Lily, may have worked most of the time as a pharmacist in this grass area, but in particular they had this classic data integration problem of new research with the drug discovery research. And they needed to be able to access a variety of internal data types from different systems, but also external systems as well from the government sites, PubMed, content repositories as well. So they had a pretty massive integration challenge and one approach had been in the past to just trying to bring it into one environment, one relational environment, sort of taking a classic warehouse approach. Well, I found that it just wasn't that it couldn't scale. It was just the time they incorporated the data they needed to, the people they were trying to ask were different and that warehouse was designed for certain kinds of queries, but the queries needed to change over time. Secondly, the amount of data that is growing, so the whole space of the industry is growing, so they had to incorporate their knowledge and that very rigid warehouse approach wasn't appropriate for that solution. So they took a heavy metadata approach to it, essentially a graph metadata approach, they already have a graph metadata approach, to align the semantics of the underlying data types to the semantics. You know, they used snowmobiles as an ontologies and industry ontologists used, and then there's other ontologies as well. So they basically aligned the underlying terms of the real-life environment, but also their external resources to this internal enterprise vocabulary. And with that, that's how it got connected, both with the external systems. The model was the model through which new applications could query. So the new applications didn't have to worry about, you know, how is the data model in these underlying systems that are either internal or external, they just code to that metadata layer. So for ease of development and maintenance there, it didn't disrupt their legacy applications on that. So this is pretty much the successful model there. We find most of the life science industry. In addition to the other industries that you mentioned going forward with this metadata approach. Just to summarize, it sounds like the problem was complicated enough, I think of medical and healthcare vocabularies as being, snow med being very complicated. If I had to, you know, come up with dimensions in Kimball data warehouses for that, it would be a huge problem. It would take a long, long time to model those things. So what you're saying is that by not having to construct by an old app cube kind of modeling process, you're still able to get the search and retrieval and discovery features out, but they could be much more agile in our ability to add to it. Is that a good summary? Yes, they would. New data sources would attach to that model, essentially through the mechanism, and that new application is just a query of that model as opposed to the underlying database. We're designed by DVAs, you know, years ago, and the other terms that are used for the columns and so forth may not be very intuitive to the web application developer who's trying to develop a clinical model, for example. Leon, do you want to interject with any case studies that you've come across lately? Go ahead. Do you have a meal? Do you have one? If not, I have a... I have one, but go ahead. Go ahead. Okay, in a brief brief. I mentioned the questions in North America. That actually was a switch from DBT to using our product some years ago. Most recently, as you've announced, they're working on a big program with external funding. They are looking to integrate data from as many places as they can into a very large knowledge base. We're all familiar with the Internet of Things, but this thing will end up with quadrillions of nodes and edges in it. It's going to be a huge project, and they're working with a lot of the national labs and private companies and so on to build that. We started out looking at the problem of the semantic one, and we were federating information across all of these domains into an RDF kind of environment. And then finally, the ontologies were really, really complex, and they needed the graph database just to model the ontologies before the light came on, and they designed themselves a layered model that's going to use infinite graph as the underlying model. Very interesting. Another one, Ian, also? There's a bunch to choose from, and it's a little bit like picking your kid, right? So it's difficult to pick out one in particular, but a recent one that comes to mind is the one that I actually alluded to before, which is a big logistics deployment. This one is actually by one of the top logistics providers in the world, like imagine the UPSS and DHLs, etc., of the world, where they are doing all of the package routing for a core country in Europe. And they realized two years ago that they would not be able to deliver packages in December of 2012, so eight, nine months ago. And as you can imagine, package routing is a very seasonal thing. Around, say, the 23rd of December is the absolute maximum peak in that business, and their software platform would not be able to deliver Christmas presents. And if any of you have, we mentioned kids before, if any of you have kids, that's the definition of mission critical. They're not going to get Christmas presents, right? And the problem was that they used a relational database, so they were unable to create a lateral connection saying that, hey, there's a bunch of packages coming into the city, sending them out to the central hub and then down out to a destination. It turns out that it's faster to just go directly to the destination from this particular package routing station. They could not do that, because their database wouldn't allow them to create that connection. So they, you know, Accenture did the project. That's public. I can't even talk about customer risk, but Accenture did the project. It was one of Accenture's most important projects last year. And Neo4j is at the core for that. And the application is really cool. They have 50 route plans that sit every day, and they work on a big cluster of Neo4j instances to plan out the entire road network of this country. And then they deploy it once per day. They deploy the smartest routes. And then as, you know, physically as the packages are thrown down a chute, as they fall, they have a couple of milliseconds, you know, as gravity pulls them down in this chute. They scan the barcode package at the top of the chute, and by the time they get to the end of it, it has gone through Neo4j, calculated the smartest route, and they actually then choose, you know, by the end of the chute, they're going to choose how to actually route it, and which station to deliver it, right? So it's a very mission-critical, you know, sub-millisecond type of application all based on Neo4j, which we think is pretty cool. There's actually a video about it online. They spoke at GraphConnect last year. I hope I'm not blocking any articles here by mentioning another conference. You should all go to NoSQL now. By the way, but they also spoke at GraphConnect, which is a conference completely dedicated to graphs, graph databases, last year, and it was a pretty amazing presentation when during the course of the presentation, he concluded the ExCenture architect concluded by saying, yeah, by the way, during the presentation, Neo4j has routed, you know, 100,000 packages in this country, in Europe. I can post the link later in the chat log. It's well worth watching. That would be fantastic. If people have any links to case studies that you guys feel are relevant, feel free to copy and paste them into our chat log, and we'll try to collect them at the end here. So it sounds like we're getting a lot of interesting stories. I think what I'm surprised at is the diversity of the industries. It seems like there's a common thread to do graph to RISL, but no one industry that's really adopting it a lot. We do have a question just come across here that's really related to the industries, and Ken Smith asked, are you seeing a higher uptake in graph databases where people have high security requirements? You know, when I think of a graph database, I often think of graphs running in a central program, and I don't think of the elaborate role-based access control that you might have on some systems. Ken's question was specifically about the need to get this something called ATO accreditation and authority to operate. Lee and I have some feedback on this because you're very involved in some federal projects. And please feel free to be real close and speak up. Well, one thing I've learned over the years is that you never mess with the security people. If there's no sense of humor, they're right and they're happy. So we actually ship a product with security in it, and that's very deliberate. What we do is that no matter what we put in the way of security, people wanted something else. We wound it up, and we let people use their existing security infrastructure with replaceable modules, we call them, in our own products. And that's everywhere. And in a federated database like ours, that works particularly well across organizations. So, you know, one organization has its own set of rules. They're not necessarily the same as another part of the government even. Even in the government, there's no single standard. And so each organization can impose its own rules on the data which it owns and open itself up to their community as needed. So we're very much in favor of helping it open, letting people plug in what they'd like, and then putting hooks for them to supplement mechanisms such as encrypted objects. And so we have people who build their security infrastructure for all the roles and user structures and so on, organizational structures using the ground databases. Emile and Xavier, do you have any comments on some of the high security requirements that you guys are seeing? Security is one of the reasons people actually have a database, at least in the enterprise. That's one of the expectations is that their data will be secure, and the access of data will be secure. And so being able to have role access is critical for all of our enterprise customers, and so for the role of the data, so for the graph data. And so that's one of the reasons, or the rest of this technology was to make sure that we could apply the same level of label security not only to a person's role, but also the data that they're looking at. So you could have a graph model, but it's a person that's on their Plastic Youth Act that's only considered that those triples are that portion of the graph that's there. And so it's critical for finance, for fraud detection, for oil and gas, for the military intelligence. It's fundamental. And so you can apply label or security at the application level, but talk to the security guys in the IT guys, first thing they'll point out is, well, you can go around the application level into data. So that's fundamental. And it's important to have security, in this case, down to the triple level, or at least node level in the database to ensure as much as possible of the access to the data. Okay, so a little bit of contrasting views there. Leanne likes to have a module of things where people customize by looking at having properties within the triples themselves that manage access is also another approach. Well, yes, just to clarify, of course, we're very, very happy that Oracle takes on that role. If Oracle has a corporate license, cross-site license, they can naturally use that security infrastructure. And of course, we just leverage that so they can hook the data in our database into their security infrastructure. So we're more than happy to let them do that job. Thank you, Emil. Any comments on the security world there? Sure, I have several comments on many things. But I think the angle that I'd like to take here, actually, is a little bit different than Leon and Xavier. We've seen a lot of uptake in people actually modeling permissions with Neo4j. What we call access control and permission resolution. That seems to be really, really popular. It's also related to identity management and entitlements in the financial space. I posted a link to one example of that. It's from a company called Telenoor. If you're a Canadian, you know them. But you might not know them. It's a top 10 telco in the world, the biggest in Scandinavia. The problem they had is that they had really big customers, which generally is not a problem, except that for the really big customers, they wanted to offer them the ability to manage their plans. Let's say that you're in a, let's take a Scandinavian example again, you're IKEA, right? And you have hundreds and thousands of employees and you are a Telenoor customer. I have no idea if this is true, but let's assume this, right? Then you want a single way to go in and manage all of your plans, your subscriptions, whether a person, a department, can call internationally, all those things. You want to do that in a central place, right? Telenoor built that application for all of their big, highly valuable customers. They built it based on, of course, not on your employers' employees, but based on the database. In this particular case, they chose PsiBase, which is one of the reasons why it didn't work, because it turns out that this database is actually very graphy. You can imagine that you have people belonging to multiple groups, several devices are connected to one or more plans. They move from one group to another and you want to centrally manage all that. And as you can see in the deck, I posted a link to a slideshow presentation that those guys did. They had response time in the minutes, but when they switched in the FDA, they got response time in milliseconds. So that, I think, is a great example of, maybe actually not what the question was referred to, but a great example of a security application that benefits from a graphy view. Good. So we're at about 20 minutes before the end of our discussion here. And so I wanted to, first of all, throw it out to the very general thing. Do you guys have any questions you'd like to ask each other about different approaches or any other questions that you think are relevant for the discussion here? Well, I do think that and some of you have been on a panel with me before. I try really hard. One of the most boring things I think is panelists that agree with each other. And I think we've seen a lot of that here. So I always try to make an effort to disagree with my fellow panelists. And there are some disagreements here around data model. And we've all alluded to that before. If I understand it correctly, Oracle special and graph is RDF. So for J is property graph oriented. And I think it's correct if I'm wrong, but infinite graph is also property graph oriented. And I think that would be a great discussion topic because I, just to put out my view on that, I think RDF is a fantastic invention. It's very smart. I'm getting an echo here. If you could mute, I get an echo from you. It's very smart. It's built by very smart people. Its final goal is to create the semantic web. And for that, it may be useful. The problem, however, is that it's typically really, really difficult for developers to comprehend. And I've been very deep in semantic web stuff. And I've taught the semantic web stack to a lot of developers, had a week-long course where I tried to teach them to model pretty simple applications. And by the end of that week, typically sometimes they eventually got something up and running. And then I've done the same applications several years later based on the priority graph model where you see the lights turn on in half an hour. There are three simple concepts, nodes, relationships between them and key properties on both nodes and relationships. That's it. And they deliver the same kind of application in half a day instead. So that's my view on why I think the property graph model is going to be the dominant graph database model. And if you look at adoption today, I'd say probably 95% of the graph database use cases out there are property graph models for that reason. So that's my view. And I'm trying to be a little bit contrarian here. And I think your Xavier won't agree with me that I would love to hear your view and as well as Leon's view. Yeah, I would disagree. So the point is that it's a very simplistic model. The property graph model is useful. Its simplicity is useful and valuable. There are other use cases where you're going to model the road of network efficiently of weather in Europe and use it for random. There are better graph models for doing that and they've been doing that for years. The other thing that you keep in mind is that there's tooling, there's third-party tooling that works on those kinds of network models. So you're not going to reinvent the visualization and algorithms or say logistics on a new model. You're basically building up the application from the ground up. Our take is there's existing type of application applications that are out there and that network model for running and transportation is not going to be replaced by either the RDF model or the property graph model. The RDF model also has the capabilities. It's a little bit more complex, but it is designed more for a knowledge basis. So it has other features that a property graph would not have. For example, you're not conferencing. You're not being able to reason. But that's a very key reason why customers adopt that model. It's that reasoning capability that you can have in a very scalable way that you can't do with a straight forward property graph model. So that's where I was referring to earlier. I don't think there's any one graph model that's going to approach. We each have their sweet spot including the property graph one and it's important for customers to realize that they're there. But not just that. There's other fundamental infrastructure issues that security came up. It doesn't matter how good your graph model or your application is going to be. If it's managed securely in an environment, the other guys and the security guys are just going to throw it right out. The next thing is manageability. Do you have manageability tools like recovery? Do you have third-party tools? Are there standards for querying this graph model or do you build up your applications from scratch? You know, big investments. Essentially, you can have your system in it to do it and they love these kinds of models because they're not standardized. They can build the whole thing up and then they can send their kids to school and college just by maintaining that. So I think it's actually to align with standards and try and move forward with standards. I think the proper graph model is still a little immature. It's growing. It's a meaningful one, but I do think there needs to be a little bit more organization in front so there can be an evolution of third-party tooling and maturing of that model. And I'm interested in the maturing of the property graph model because there is value to complement the other types of graph model that exists. Okay. Very insightful feedback for both of you guys. Any feedback on property graphs versus other graph models? Yes, of course. I agree and disagree with my fellow panelists here. But I'm not as worried about the model. The reason being we have a very strong store in which we can deal with linking things in multiple ways. And so we have people using RDF. We have people adopting something like a property graph model. And we have people who stick with pure schema to get extreme performance in very specific algorithms. So I've seen much more bothered, as Emil knows, about getting a standard graph query language for the industry. I think it's holding us back. I don't mind that we've been at small as a start, but it's not great. We all know this issue is great with RDF. It's not good for hypergraphs. Maybe we should listen to the community and look at cipher and start from there and extend it. But I'm much more worried about the query language than I am about the model, because I think we should be flexible in that respect. Just take that comment before we're just going to have a couple more questions open it up. I think the question about standards is very critical. I think Xavier pointed out that if there are standards, there are tools, and there's ecosystems, and there's training and books about things like that. If every one of our graph databases had a separate query language, that would really inhibit the adoption of a lot of people and also prevent third-party developers from moving towards graph databases. They have the fear if they tie themselves to one engine and that engine isn't popular in the open source or in the product, but they've got a dead end there. So they also want to talk about the potential for standards beyond Sparkle. I think everybody knows that Sparkle is the standard for RDF. What about standards for property-based graphs? Xavier, I think that's an important question. And I wouldn't approach it by trying to apply the Sparkle standard to, say, a property graph. I think that the use cases for property graphs are different. I think there's some older ones, but their sweet spot is different. And there are APIs that can work against that property graph model. And they can work for some cases, but they're just not expressive enough. You know, which is the database is the expressivity of the language, which is the fundamental differentiator. But as you say, the mainstream, it's very likely to hit mainstream without a standards-based active model. So I think there's some opportunity there for an organization, either the W3C or others, to explore that or an industry, you know, a community of industry groups to come together and say, look, for the good, we can lift all boats here through a common-access layer. As Leon is saying, you know, from the database level, it doesn't really matter, you know, what the structure is in the database, what we need to give us the language that needs to be standardized in a little minute, but it's not that big. It just needs to have a standard way of doing it. And companies like Oracle are a little bit low to adopt or create a new language that will be viewed as proprietary. We'd rather have the industry come together and advance a real language that can be used for all. And several vendors can invest in that, including our company. Well, I know that your tools have been used by a very large number of Java developers. Do you think some of the techniques in your query language could be standardized across other databases also? It definitely could. You know, Cypher is our query language and it isn't tied to Neo4j. It's tied to the property graph model. And it definitely has been. The immediate potential, I should say, consequence of that would be the ultimate demise or at least the realization of graph databases. The problem is that we're way too early to standardize. And the industry, we don't know what we're doing yet. We're very candid about it. Like, you know, even though I've been working with graph databases for 13 years, you know, I've learned so much just in the past 12 to 18 months, right? I mean, I think three years ago we probably had 10 production deployments of Neo4j. Today there are thousands, if not tens of thousands, and hundreds of paying customers. And we're learning so much still on how to actually use graph databases. And I think premature standardization is not all evil, but a lot of evil. And the goal is to slow down innovation in the graph space then to standardize. But that's my goal. I want to get graphs in the hands of thousands of developers. And standards is not a goal in and of itself. What you really want is to avoid vendor lock-in. Vendor lock-in is horrible. You need that at a normal cost, but at a normal cost, right? There are a number of ways to do that that are not standards and that's a really sound architecture. Minus the amount of, let's say, the percentage of your application that has to change if you change database. And that's just sound architecture. And that's the real way, I think, to get around vendor lock-in. I think standards today would kill us, but we don't have any standards five years from now. I think that's also really bad. Sometimes we now in five years from now need to see standardization in the graph database space, but today it's way too early. At Neo4j, we see probably a hundred times or a thousand times more graph database installations than what's out there. And so we have a lot of data on how people use graph databases. But we still don't know everything. Nowhere close. And trying to build this as a standard, it's a great way to slow it down. I agree. I agree. I agree, but I think maybe part of the problem here is maybe Amir is thinking of standards the way that we used to think about developing SQL 2 then SQL 3. I can't remember whether SQL 4 ever happened. It was eons between these things crawling along with hundreds and thousands of people involved. Now, I'm talking about the community being dynamic about this and saying, look, there's change of direction. And let's say down a couple of grand rules. It could be as simple as saying, we want something that certain tool vendors or certain communities would like to use. And then some of those people and evolve this thing to meet those requirements. And if other people join in, great. I've watched things like the Object Management Group. I don't want to really implement anything the Object Management Group does anymore. We don't want that. I completely agree with Amir on that. I also agree with him that probably three or four years I'd go in the era of three or four years. The reasoning for that, in my mind, is that I've gone over and over and over in different forms of databases, network databases, et cetera, et cetera. And if we don't get it soon, people turn off. If we don't pull them turn off and the Object Database world way back because the EMG couldn't find people with the tools that we've got to pull in. If we don't do it, they'll do it. And that's not the best way for it to happen, in my mind. No rigid rules, I think, but there's a set of common requirements. And if that applies, I'll come in and say, okay, we'll become part of the Cypher community and bring the entities of these very high-end users that we have. And we're happy to do that. Very good. This is a very good discussion. There are a couple of questions that are coming in. And actually, they're also about standards. And maybe I'll throw one of those questions out that has come up from a couple of people. What about the Tinker, Pop, and Graham ads existing standards? Anybody want to comment on those? Well, let's have you address them to sort of point toward me on that. So those can be considered ad hoc as opposed to de jure standards to sort of... And so I think they're useful, but they're not... I think what we're talking about here is a query language as opposed to an API access to API. So those are useful. There's one... Those are somewhat accessible. But I think what we're... I think those are just here. And the need for it is a query language on that. Otherwise, you're going to end up with these end-to-end vendor lock-ins. And as a result, I'll throw up a proprietary approach on that. And that's essentially what we're trying to... I think what we foresee, if we want to make greater databases prevalent and widespread as reliable databases are now, and they'll each address their specific problems, you need a standard query language. The industry tooling community is not going to be investing tooling on a single vendor, a small single vendor to address that need if they see that that database vendors will be supporting that, whether they're large database vendors or small database vendors. It means that the risk... It won't reduce the risk for the customers if they have choices of different databases that are aligning with that standard and different tools that are aligning with that standard. That creates the ecosystem there. Yeah, I think we will likely have some form of standard within the next three to five years, but that's a process. It needs to start at some point, and these things don't happen overnight. In order for someone to put a specification on the table and they can work from there, but it's a community process, and moving the process forward. But I think, as Amil was alluding to in his first take up of it, and we're seeing it in ours, we need to take this to the next level. I think that opportunity is now, and the opportunity to actually take this mainstream through the common access method. Okay, so we're running up about five minutes from the end of our session, and I just wanted to thank everybody that participated, but before we exit, I'd like to ask each of you guys one of the most critical features that you guys are working on right now for your next release. What's the new hot thing that you guys are going to be releasing that you can talk about? Leanne, you want to start us out? I hate to disappoint you because objectivity has always had a policy of not pre-announcing. We've been very strong on having our customers use new features, and then when we're all happy with them, then we announce a release. But the next release is coming very soon. There are always performance and scalability improvements in our product, and we've got some interesting new features on the way which will miss more competitive with some of the newer products that are right there. Okay. Anything new coming that you want to talk about or just general trends? Two questions. New things or general trends? All right. Let me address both. So, I mean, we do develop in the open, right, the open source project. So, our code is available on Github, so you can see, you know, in real time as we build out the new features. And so, the 2.0 release is coming up this fall. And Neo4j 2.0, which is going to be a significant release. The most important part of it is going to be support for what we can build in indexing. And that means that you're going to be able to take a node and you're going to be able to label it as, say, a person node or a code and whatnot. And then you're going to be able to associate indexes with that to say that, hey, you know, if you're a person you should have a social security number and please index that so I can look up all persons by social security number. The reason this is really important is that then it's going to be a first-class citizen. Indexing will be a first-class citizen in Cypher, which is not true today for Neo4j 1.9. So, that means that you're going to be able to use just Cypher as no Java, no embedded API, no REST API, just pure Cypher to build your application. And we think that's huge. So, that's one big thing. The other big thing is that we're doing a refresh of our web UI to write it to be completely Cypher-oriented. It's going to be, I hope, a great at least starting for a developer environment around writing Cypher. So, that's going to be awesome. And then we have, maybe it's a super exciting thing, but what's important is that we're doing a window where we're doing a Windows installer. And that sounds kind of trivial, but it turns out that we have a lot of uptake in Windows. A lot of people downloading us in Windows and our Windows experience right now is honestly, it's very manual. You need to install Java if it's not installed and things like that. So, it exposes a little bit of our underwear, which we've never liked. And we're going to improve it with an actual real install experience, which I think is going to actually just make working with Neo4j on Windows a lot smoother and easier. In terms of trans, let me just address that much, much rougher. The big trend for us is that we're going to blow away all the barriers we have in Neo4j to adding lots and lots of data. So, we're working on supporting petabytes and trillions of nodes and relationships in the 2x release. So, that's going to be super exciting for us. That's one of the most important trends for us right now. Very good. Savi, what's in store for you that you can tell us about that is? Yeah, I mentioned a couple of things that evolved in the last three months. So, first of all, our graph implementation on our relational database. We developed the Sparkle 1.1 standard specifically for these RDF views on relational data. And this is important for a lot of our enterprise customers that are trying to create these metadata stores, because what it does is you run this operation and it basically creates a view on a relational database. So, what that does is you can keep your relational databases as they are, but we've just created a view that basically represents it as a graph. So, you can basically query it as a graph, and it sits there. So, you can see the graphs that are essentially behind the covers of relational data. Very powerful for a lot of modeling. So, you're taking existing relational data and modeling it as a graph without having to transform it into a graph form. Very, very tremendous interest to our enterprise customers. The second one was the reduction of graph data model in the Oracle NoSQL. So, now you can use the Oracle NoSQL key value store as a RDF graph repository, and then use an enhanced Jenna layout and a framework to access that and utilities for loading and querying and optimization. So, those are two I'd like to highlight. Very good. Well, we're right at the top of the hour. I just wanted to thank our expert panelist. This has been a really great discussion. I think we've learned a lot. You guys all have different insights and a lot of good stories. And, Sander, are you still there? Yes, I am. I just wanted to mention to everybody that you'll be seeing a lot of these people at the NoSQL Now conference in San Jose starting on August 20th. Just to reiterate, and your words, Dan, thank you, everyone, for this great discussion to Leanne O'Neill and Xavier. That was just phenomenal, Dan, for moderating. And just to remind everyone, we will be posting the recorded webinar to Dativersity.net within two business days. And I will send out a follow-up email to let you know the links to the recording and all of the great links that everyone posted in the chat section there. And a big thanks again to our panel for this discussion and to Dan for moderating. And you can learn more about all these great graph databases at the NoSQL Now 2013 conference in Expo in San Jose, California, August 20th through 22nd. Thanks again for joining today's webinar. We hope everyone has a great day. Thanks, everybody. Thanks, everybody. Bye-bye. Thanks, guys. Bye-bye.