 So the topic for this panel is query languages. And I'm going to start it out by, I'm going to put on the hat of the developer. I would like to write software, and I'd like my software to run everywhere. I don't want to write five different versions of software for five different databases. I have complex things I'd like to do in my software. I'd like to manage documents. I'd like to manage graphs. I'd like to have it be performant. I'd like to run in clusters and be reliable. I'd like it to use the indexes and all those complicated things that I have built. And I'm kind of upset right now in the NoSQL space because we don't have common query languages yet. So what I'm doing is I'm just writing all my code for relational databases. And I'm just staying here, and I'm going to stay out of the NoSQL space until a panel of experts tells me there's hope. In the future, that we'll be able to do some, maybe not one query language for everything, but maybe a fewer query languages. So with that, I'd like each of the speakers just introduce themselves, tell us where you're from, and tell us any background or any interest that you have in query languages. Jim, would you like to start? Hello, folks. I'm Jim. I'm Chief Scientist at Neotech. And I'm a fan of the query language Cypher for graph databases. It's going to be a short panel if we all just... I haven't got more. I thought I was watching that. I thought that was going to be a bucket list of wishes. I noticed the absence of unicorn. So I'm now... I was part of the CODESOL database task group standards for the network databases in 1972. I had a feeble attempt at trying to change SQL2 into SQL3 with objects with IBM and Oracle. I was part of the definition of OQL for the object. Oh, you were? Wow. That's a long time ago. I skipped HTML because I was bored at the time. And I really, really, really want them to get a graph query language out there. And if we can do it via a no SQL language, I'll be very happy, but I date it. And we'll go from there. But I have to say, Dan, you're what I call a troublemaker. So two people and I'm not looking good here. So my name is Matthias from 20 milliseconds. I've been in a query language space also for quite some time. I've been a member of the W3CX query working group. And I've learned about standards and how they are being developed. It's tough. But in the long run, of course, it's probably worth it. So I'm not sure what to answer to Dan. But I see the no SQL community here. And I see that the no SQL community, and if I go into the exhibition, I see all those great data stores. And I'm not talking about graph databases. Well, we've got great data stores. That's not too much to say. But everybody here, and I'm pretty sure you all agree with me, we have solved the horizontal scalability problem with those data stores. And that's what no SQL is great at. But if you look at how people are developing applications today with those no SQL data stores, I think it's a nightmare. I was talking to a lot of data scientists today that work with no SQL data stores or document stores like MongoDB. And what their job is really hard. They have to write, based on the query languages that exist today, really tough queries. And each of them is writing for each query that they do, 400 lines of Python code. And then they're having the next problem, and they're writing another 400 lines of Python code. And then their colleague comes in, and they hand over the code to him, and he says, wait, that's made too complicated. I don't understand it. I write that again. And I don't think that's where we should go. And if we care about productivity, and it felt like no SQL space does care about productivity, then I think we should do something here. Whether it's a standard or not, but I think the query languages that we have are not good enough. Now, I attended your presentation, and I saw that you were doing some pretty complicated queries on multiple different kinds of data sources and from my memory, it was about 20 lines of code. And from what I seem to remember, if I had to do that in a Python language, that would have been two, 300 lines of code. Yeah, I guess if you have a high level declarative query language and you're willing to learn from the past and how query languages have been developed, I think you can easily gain one to two orders of magnitude in lines of code, which means fewer bugs, which means less time, better maintenance. So let me now be the devil's advocate. We have a potential query language, but one of the things we're finding is that, although we've solved some of the scalability problems, there's a lot of different types of data models that people are using. And let me just say in the graph space, we have property graphs, and we have RDF. And RDF has a standard, Sparkle, but it seems like a lot of people that are doing property graphs can't, or that language doesn't work for them. They want to be able to do something else. Any guys want to comment on that? Obviously, Sparkle isn't taking over the world. People worked very hard for it on it, and it has solved some problems. But, for example, Neo4j doesn't work out of the box with Sparkle. If you prefer to work in Sparkle, you can drop the Sparkle library on top of Neo4j and pretend it's a triple stock. Absolutely. So it's your choice, right? We're not dogmatic. You can drop Sparkle on top of Neo. You can bind to it in a low-level Java API and write hundreds of lines of statically typed code. You can drop Gremlin on top of Neo if you fancy doing imperative path-based programming. Or you can do declarative programming, declarative pattern-matching programming with Cypher. On a personal note, I find triples quite difficult to work with as a mental model. I don't find them to be very rich. I don't find them to be intellectually comparable to the ease of use that a property graph has. And, therefore, that's why I find myself wanting to explore a graph as a graph, not as a disconnected set of triples, and certainly not as something that I inference through Sparkle. Your mileage may vary. Yeah, I tend to agree. We prefer people to import the RDF and then use our native interface. Whether I'm talking infinite graph, the graph database, or objectivity, you know, we can get it C++ and so on as well. OQL had some elements of graph in it, but not enough. And, you know, right now, if you're going to say, is there a really good single-purpose graph language out there, no. You're definitely okay with Sparkle with RDF. I like Cypher as a first attempt at something to handle property graphs. Where, somewhere in the middle, where you can use it, where, somewhere in the middle, we're still procedural, very strongly expressed queries that you can save and rerun. We haven't gone to Claritive yet, but I don't really want to go to Claritive unless I go with something that looks like it can make a standard. If we can take Cypher with the community and move it forward to do the things our customers want to do as well, that's fine by me. So I think we've... We're going to be done yet. Cypher's still evolving. Neo's community is building lots of new stuff. We're building lots of new stuff. Our customers are asking for lots of new stuff. And if you look at how you get things rolling, you can either ignore standards for a while and go your own way and hope you can make it. So you play your own furrow. That works often, but not very often. Or you can modify an existing one. Never the best choice, but lots of grinding. Cypher's not a good place to start. OQL might be better. Cypher is probably the best for us. It should be fairly easy to embrace what Cypher does with Cypher. Or you can just forget the standards thing and then you end up in chaos. And basically I've seen at least three different database technologies over the years which failed to make it the mainstream. Because they didn't get the tool vendors building stuff fast enough. So let's remember what's at stake here. People that are going to depend on people like this. How many people here have heard of OQL? A couple people. OQL is the object query language. And it was an attempt by the people building object-oriented databases. Versaunt and Gemstone and some of the early pioneers in OQL object stores to create a standard language. But I don't think the vendors really embraced it. We all looked at it. At least one did. Poet started building stuff. Poet was doing that. I was interested in saying we're not going to build that. We want the tool vendors to do it. Then we couldn't find the tool vendors. Then we found Powersoft that was really the force in the SQL world of time. They committed to building an OQL tool. Which was wonderful. And then Sybase bought them and that was over. We had about three months to our second release which introduced new languages. So we took SQL and modified it. We bought an SQL engine. Put object-oriented extensions in it called it SQL++. We still use it a day for QA. And there are tools that can use it. Because any ODBC tool can use it. But it's horrible. So the lesson here for me is I was doing development with Java and actually Smalltalk I should say and Versaunt quite a while ago. One of the things I wanted to do was I wanted to build products. But I did not want to lock myself into a single vendor. So I was saying we're going to wait to see how these OQL standards and we went off and did other business ones. So one of my questions is how many people are there out there that would like to build really cool applications and they're just sitting on sidelines waiting for standards to shake out in the NoSQL world. And as soon as these standards become viable we're going to see not just a 10% but a three-fold increase or three orders of magnitude increase in the number of people using this to solve business problems because we've wrapped them in solutions and then they just disappear in the background. That's the audience. Yeah, so how many people here, if you were software developers, building applications would think more aggressively about building a NoSQL solution if you had one query language that ran on every product here. Wow. I think we have a couple of business plans that are sitting on the shelf if we could do this, if we could figure out a way to do this. That's one of the problems with standards though is who's going to pay to have the standards developed because standards take a long time. Yeah, I mean I've been on the W3C X query working group and each of the standards, each of the new revisions of the query language takes a couple of years and I've been in those working groups every week talking about the things and it takes a long time. On the other hand, there are a lot of tough problems and standardizing it and coming up with the right semantics is a tough job. And I think that's what the NoSQL community at the moment doesn't see. Each vendor comes up with a quick query language every week they add another new feature they can do smarter than in one week then they can do a greater than comparison the next week and they invent query technologies as they go and I think that is not looking enough into the past and what has been being developed there. So I was talking to one of the VPs of one of the database data store vendors and they said, yeah, we don't care about query technologies we need to solve a couple of other problems, the query language later on that will be easy, it's just in Cramer and you're done. And this I couldn't disagree more with. So I think a good query language, a good declarative query language is very hard to do we need to learn from the past and whether it's being a standard or not, that's a different thing. I'd like to invite anybody that has questions raise your hand and you can ask individuals or we can all attempt to answer the questions I do have one question that is really on my mind about the interfaces between these databases and the query tools. It seems that if you had a single processor and you could count the number of rows and tables and people wanted to join you can use the statistics on a single processor to optimize your queries. But now that we have these clusters and the clients now have to have information about which records are in which nodes of clusters that maintaining that information in a distributed cluster can be expensive sometimes. So when I do a write to one I need to update information around that cluster about how that write will have impact on future queries. So here's my question is do you guys think that writing query language for distributed systems is going to have a good trade off even though we have more information that we can use in these clusters? Objectivity has always been a distributed database and so we've always used federation of databases which were homogenous at first they're just our own. And so when you launch a query what used to happen was data was bought to the client and then we come through it and return what you want. We changed that four or five years ago with a parallel query engine which distributes fragments of the query out to individual query agents that are little objectivity applications that then go in and find the data. And if the data is in the bit where they are great if they need to go somewhere else to complete the query that happens because they're applications in a distributed database environment. So it's actually not hard to make a system work. We use statistics to speed that up. What you're implying there is that you've got optimization going on that can take advantage of it. We don't need that with navigational queries and with objectivity queries you don't need it because you're not doing any drawings. Cardinality doesn't matter. The programmer knows better than to start at the bank and goes through all the transactions to find out if this customer is connected with that bank. You wouldn't do that. You start from the customer and look at his transactions and see if that's connected to the bank. So that optimization is done by the programmer before they start. So if you need to optimization, yes stats are good, but they can be distributed. We do distributed counting when we need to. If you're not doing that then it doesn't matter. I would say one thing though once you start spanning different databases for Federation and where you are for instance, then the whole game changes because you're farming out bits of the query and you have no idea how long those other agents are going to take to give information back. This is if you did a query on Google and also wanted 12 windows filled by the web servers behind it. You don't know when they're all going to fill out. That's true. That's always going to be there and Federation falls down and the thing is too big. Keep it small. Low latency network, high bandwidth network great. Low latency, unreliable. You need to play other tricks. It's clear. Jim Cray said if you want to have fast queries you need to ship your queries to the data. So there's no way really around that. If you're going higher level Federation then it's becoming more tricky and then you need to play other tricks and maybe have statistics or cost models for your underlying data. Collect the statistics. At the higher level, use them to help farm stuff out. We have a placement manager that allows you to say put stuff over in that country database that country database. If we go looking for something in Europe we're not going to look in any Asian database because we know it's only going to be over there. The more clues you can give the query manager in terms of placement the better it is. It's particularly hard in large homogenous graphs. Every node is of the same type and every connection is of the same type. That's your worst nightmare. Because that can get really bad when you try to do some algorithms like working out maximum span and things that have to be done across the whole graph. That's some appalling domain modelling and genius graph. Only mathematicians have homogenous graphs. We have actual graphs. If you've got that, you've got a university professor that's trying to model some discrete maths. Thank goodness. The more heterogeneity there is the more optic classes the more types of edge the happier we are. We're skewed here, right? This is an incredibly skewed panel because you've got two graph databases and a query dude. We are not all representative of the range of different data models. He does represent two types. There's at least four that I could like spit out before we even get into like splitting S, right? What we have as an advantage as graph databases is we have relationships. If you give me a declarative query a bunch of metadata about the kind of patterns you're looking for I'm going to use those relationships to my advantage. I'm going to use locality at right time. I'm going to use caching at read time. There's no runtime to optimize that query which means actually we get a head start in terms of query optimization because there's a bunch of metadata that you guys as users of graph database put into our databases called relationships or edges or whatever you want to call them and they give us such a head start in optimizing queries. I think the bigger challenge is if you've got one of the aggregate data stores column family store, key value store, document store and they don't have any linkage or at least formalized any linkage between records that's difficult. That's correct. Right. Yeah, it sums up nicely. So your basic thesis is if you start with a graph model there's enough hints there that you can get relatively fast queries even on distributed platforms. If it's properly form-related and actually the more variety you get, the happier you are. So flexible schema is our friend because we don't care the more the merrier. So homogeneous data tabular or document type data, you need to gather statistical and cost-based models and then use those to optimize your queries. Even without a join you need to figure out which index you're going to leverage in your query and if you have a bunch of indexes and you don't know about the selectivity of those predicates that you use and you don't know which index you're going to use. So you have that information to do the optimization. So people are not doing that do not have that today. A lot of relational databases don't have a cost-based optimizer. Most of them are still implementing heuristics and there's still research going on in those fields. So I don't expect that the NoSQL community will next year have a cost-based optimizer with perfect statistics. But still there's something to learn from this. You should close our code sometime next year. Yeah. The other thing that occurs to me always when we're talking about query languages someone invents a new one every week and it's getting very tiresome. Someone invents a new file structure every day that's even worse. There are only really four ways to get at data. Let's not forget that there are only four and I'm not going to tell you what the fourth one is. So if we build something that can get at it it's not to do with the four varieties of NoSQL database we're seeing. This is a real primitive storage engine right down there at the disk head stuff. There's only four ways. So if we cope with that and then refine it upwards we should be able to build something that embraces all these models. And what we need is someone with the mathematical brain and time and simplicity that's a codball with relational algebra just look at it again and come out with a model. There are some guys in Poland that are not close enough. Some guys in University of Texas had a crack at it, not quite enough. It is doable and if we do at that level and have a kernel for a query language like you build toolkits or other things maybe we can build a stack above it but it's better. I just have time I would like to just get out. So what you're saying is that just like we're looking for the grand unified theory of all physics you're looking for the unified query language for all these different types of data. I'm saying let's start with the atoms if you like let's start with the quarks and deal with that and then come above it rather than coming from the top down which is often a nice way to look at it and abstract it. I don't think we need to go that way. I think we need to look at the primitive to get that right and the rest of us can build things around it which at the top level look to the user as if it's a standard uniform whatever but what's going on underneath the covers is completely different for each of the different engines underneath. Yeah, that would be the ideal I'm asking for unicorns that would be close to what I've asked for. The OMG endorse your unicorns then you know it. I might spend some time I'm due for a six month sabbatical it's due in 1988 or 89 I think hahahaha Anytime now Any more questions from the audience here? Don't be shy I have a question I have a question How many different query languages have you used over your life think about it for a moment is it one to ten? Anyone only used SQL is there anyone here who's only ever used SQL? No Five? Anyone used less than five? That's probably very young But that's actually tremendously unlikely considering a lot of web pages you go to are formulating their own informal query language I mean it's horrible there's dozens and dozens and there's flavour of the month you know and for property things, if Cypher's flavour of the month and we jump on it you can make your life that two years from now something else is going to be out there but it will still have a terrible name hahahaha I think I saw a presentation where people were using the Lucine query language for doing full text with proximity searches and things like that so it seems like there are many different variations of these things Can we get variations of variations? I do sometimes wonder I really do I grew up in a very highly visual world where you point and click on things you see the picture you rotate it and bang and it looks some more and so on so I've never actually been a very strong fan of queries ObjectivityDB at release one had no query language probably the first database ever released as a commercial product with no query language whatsoever it went in with a key value navigated through the association people built solid models people built whole products based on it and everything they did was highly visual they never used a query language and later we got into the intelligence community they really do worry about locality and where people are and other stuff how tall they are and how many legs they've got and then you start to want to do it but you can do all that with query by example so you put the right pictures on the screen you actually don't need a query language you let people refine stuff so I don't know so maybe we're looking for the Holy Grail that's pretty fascinating right because Cypher is pictorial admittedly it's asciot pictorial but it's pictorial that's pretty interesting and we learn also so much from visual analytics that you don't have to express it declaratively sometimes it's a lot better to get hold of it and grab it I mean have you ever tried to catch a small pig or pig a greased pig I am surprised really no hands because we do that all the time in London oh pig marvellous I grew up on a farm so take your grandkids to a farm and you let them loose and say go catch a pig each it is really funny it happens in the west country but you see I live in a city by the way do not toss with the same brush it does not work it does not work same as flying a plane but now you can almost do a flying it does not work to type the query and expect the right pigs to come to you it doesn't happen now so I think slow ones though but they don't taste good I think and people don't love to take a look at it because for whatever reason but I think it's worth it to look at XQuery which has a history in OQL which has a history in SQL and we've extended XQuery with JSON support and I think it is a nice declarative model it has an algebra behind it a lot of people have spent time to develop an algebra to evaluate XQuery so I guess that also might address your concerns it has an extension for full text search that allows people to do more than the Lucene full text query really declaratively you can describe contains text within distance of four words so I think it is a very nice extension that allows you to declaratively do full text search it has an update specification that I think is nice it has declarative updates which I think a language not only queer language but an extension of it should have Sparkle didn't have that in their first version and so people don't like XQuery I've learned that for whatever reason because it has the X word but so what we did is we removed all the angled brackets from XQuery and put the curly brackets from JSON in and if you're really looking at it it's the same thing and the concepts out there, people love them and it allows them to do the complex queries that they need to do query by example it solves some problems and it's easy to get started with but then you still want to do more complex queries and encourage people to take a look at JSON it's an open specification it's not a standard or anything anybody can contribute to it at the moment and it's a very high level declarative language that allows you to do a lot of complex stuff sorry can you extend it and do what Cypher does and vice versa I can see it being much easier to take Cypher and embrace JSON or whatever but I need to I think you can go ahead and express eigenvector centrality I think you can extend it, yes it doesn't have the support for that yet but I don't think it's hard to I know there has been an effort to extend XQuery with Sparkle so X Sparkle stop it that was actually done on your upside of the pond wasn't it? oh crap see your tax dollars just paid for phone call snooping mine pays for like killing kittens, it's great oh is that too soon can I not make jokes about that yet it's like ring ring hello when I say what was that for, it's like take your namesaw and turn it into a pink candle I don't know I want to just mention the fact that I use XQuery quite a bit and for me it was an ability to actually eliminate a middle tier of software that really gravitates me with SQL you can't return a web page with all of my XQuery code I can eliminate an entire middle tier of software and I can do my queries and build a web page directly it's a functional programming language so I can use all the function I have extensibility I have a huge number of XQuery libraries that I have at my fingertips I can do FTP in the middle of an XQuery I can do cryptography there's a new EXPATH function for doing bit operations with EXPATH so it seems like my productivity when I use XQuery goes up dramatically especially since the people doing the queries can actually build the structures and then the only thing we do is style the page with CSS and that's a separation of concerns you can do that and we try to sell this and our product actually can do this but people love their middleware so don't tell them that they can just remove it because then they're not going to buy your product so if you sell it as a query language people will discover themselves that they can do it and probably that's what you did as well and then they're going to love it but that's just the experience I can't say Cypher cannot do FTP and it's highly unlikely we will ever allow it to do FTP because that's a separation of concerns I think I'd like to modify so clearly I mean if you want to have a query language and it's a pure query language it's not going to be non deterministic if you're having FTP either if you read or have a non deterministic query language or you are going to have side effects if you push that so without those extensions FTP is not a good thing to have if you want to have extensions and do more of that kind of stuff then you need to extend your query language with such concepts but then you don't have the optimizability and stuff that you want to do someone say something it's like an immense gushing over here now yes, a little bit particularly at the National Visual Analytics Consortium and those guys Pat Hadnarty's group at Stanford came out of that as the Arvac Regional Visual Analytics Consortium representative so yes, quite a lot of looking around there no really staggering results I think part of it is that you need to talk to the end users and they weren't doing quite enough of it even though they had access to CIA and SA all these guys they really weren't listening hard to the analysts so what they've got at the moment is reasonable for business problems and some scientific problems but if you talk to the average guy from the intelligence community and ask him to describe his everyday query an hour later your your head's sinking and your ears are ringing and you realize that it's not an easy thing and the more you the more you learn about complex queries and particularly visual analytics the more you find out that actually the query doesn't really matter how you express it as long as you bring the bits together that's why I'm all for building from the bottom up rather than the top down if we're given the building blocks a lot of these people can put the rest of it together themselves so I think that's a good one I think there are excellent examples in the can-can world there are the most skilled query people in the world they can drill right down inside a 747 and we'll around it without writing a line of code without typing anything so there's a lot to learn on that side but if we want to do it machines to do it that's different because they haven't got the eyes and the hands to do it so you end up wanting something that you can execute or re-execute and I'm closer to the Cypher than this I think you can see that I am to try and modify an existing language you said the people in the CAD-CAM world yes originally they were using things like OQL object query language to store their objects still a lot of people have done it a lot of things like now Hong Kong airport was built using our system inside a system that used to construct it and all the rest of it build, execute, 7777 787 all those things are objects they're all visual you can walk around inside them any metal was touched or any composite again they've got a very specific role and then they want to run algorithms which don't rely on the queries the algorithms they then run are working out the electrical connection between chips and what's happening when you flip this or flip that or what happens if I push this it's quite different from looking at data mining in a big data warehouse it is very different from the other techniques what we don't have at the moment is taking your various big data stores hitting it with a few simple commands and putting something up there that you can then say okay I want to go here, I want to go there that's what we're missing we're missing a big chunk of the puzzle so what I agree with you at least with one thing which is we need to talk to the people who use it and the people who use it are not only developers absolutely, it's end user it's end user, it's analysts that would usually use Excel for doing something and I think we need to give those people a language that they can use that they can understand and the NoSQL data stores are far away from that that's a really sweet thing statement I mean like I have a guy who's on my sales team and he's a Belgian guy and he has a penchant for Belgian beers and he's not extremely technical but he can use the Cypher query language to manage his beer collection actually he's brilliant right go to his house, tell him your preferences he'll run a Cypher query, then he'll disappear down the cellar that way it's not an Austrian cellar it's just a Belgian cellar, they're safer and he'll come back with the right beer for you based on not only the kind of beer preferences but the brewer and his father anyway I agree with you that Cypher is going into the right direction I think it's becoming accessible now to I think the idea of like my grandmother using a query language is kind of bit unicorny but I still think you have to have some technical prowess to be able to grasp even a humane query language we shouldn't set expectations too high but it'll be accessible to the CEO because that guy is always a bozo oh shit we're being filmed I thought my boss isn't here I'm safe to say this I agree with you what we do is we're talking to some guys in the financial industry one of the guys is one of the inventors of XPRL which is a data format to transfer and exchange financial information it's going to be mandated by the SEC next year he's a relatively technical guy but and he was trying to apply no-SQL technologies to his business needs and he couldn't do it and so I think we're still far away from that I'm looking the other way I'm looking at my phone because I have Graph My Life which is an app built on Infinite Graph that we just use as a demonstrator and I can poke on a few icons here and I can find some photos I can find out who created those photos I can find out whether any of those photos were taken by people who are in my social network some of whom are here and I can do that without writing any query at all I'm just poking about you're building a query through the graphical interface by adding constraints so I have a subset of maybe a full query language but a rules engine so I work a lot in the federal space we have a lot of XML data we found that we can teach people how to write business rules schema tron and type things by teaching them path expressions and we give them a graphical tool where they can click over a thing extract a path and put it in a business rule so they don't need any Java they don't need to know object allocation and memory and things but they do need about a week of training and they can build and maintain business rules and that's those are the kinds of many query languages I wouldn't say XPath is a full query language but it certainly is powerful to do complicated things but then we can also build business rules and not having path expressions in JSON seems to be difficult sometimes so I always keep saying I want to have simplicity I want to have the simplest structures but I also want to have path languages yeah I agree question very specific problem so it's almost a scenario based documentation you're still going to start on the language specific adapters thinking on Cypher again you just type Cypher right into the console and you're when you start on the language adaptations that's where the documentation challenges start once in a documentation version it's very different if you've got that space so you know that's okay from that and I'm with you on that perspective however as a company trying to build software and deliver it we have to worry about QA and quality we support about a dozen different platforms in 32 and 64 bit 6, 7, 8 more than a dozen operating systems 8 languages blah blah blah now you give me another language and I say people are going to ask for a lot of resource because we've got to test everything multi-way now if you say okay do it in the open community I had this discussion with Larry Ellison on our panel once and he said oh it's easy you know heterogeneity is no problem you just write a converter from X to Y so I said okay 400 converters who's going to write them am I going to write them as the audience is going to write them can we depend on the community to make sure that everything works in every direction you know and it can't so we proliferation is great innovation is great but narrowing it down to something that we can all get behind is what made SQL run it's why 20, 30 years on we're still using SQL for building very big systems that's a very good point when we've talked about standards in the old days some standards had to be cope with like OSI, whatever it was you took the person who was the least valuable on the team that you wanted to fire but you sent them on the standards that's what you did you sent them off and you gave them an expense account and you said don't spend more than this and see it when you see it, see it Christmas maybe that's what you did now it's completely different we go out the community 5,000 people form little clubs you guys know how it works and you can make things happen very fast and you can find ideas you can try things and throw stuff away so when I think of a standard today I don't think of that old environment I think of something highly dynamic that moves that we can get behind you know I don't mind trying to stand on top of a snowball I'm prepared to try I don't care and a snowball more than something else I don't care either as long as I got something to ride to get me from here to there and this is a jump on there with me my customers, I'm going to be happy but I need something I can't say yeah, Cypher's great but we haven't got it yet we don't know what we're going to do next week I'd like to see these guys they're federating everything but forget the performance that's the worst that's going to happen I think we've got to do something for ourselves the community will clearly try it and if you have enough adoption that's the standard so that's a key thing if jsonic worked on two or three of the major players there'd start to be a base of software developers that would start to use it wouldn't that pressure the other people to come into line that is we just need this critical mass before we have pressures of software developers getting the rest of the people to adapt to so there are ways where you can reach a threshold and maybe the same is true for Cypher if you had a few software packages that start to depend on Cypher then the other graph databases would have to support it but you don't convince people on a horizontal query language you need to that's getting back to giving people something that they can use you need to convince people in verticals that this query language solves their problem and if you do this then you get enough adoption and then you get into what you call standardization or defective standardization again if our users could use Cypher they'd be using it and unfortunately rather than being open these are people who live in dark glass boxes so you cannot see it underground we can just get their ideas out dude I have Swedes their whole country is night time I know I know but you can ask them questions I'm not sure you ever get a straight answer like from the killing but they do have good fish but we can get those people to say look you've got to be able to do this if we can then get the Cypher community to jump up and say alright you know like this let's do it we're all for that we'll join in and then those guys are not interested in JSON or other things so we've still got at the no-seek level we've still got the same issue and that's why I always say no grand up not top down are you all agreeing? yeah I'm dying we've got to find something to disagree on so you can keep Emile happy sorry that's an in-joke but Emile always likes the panel not to agree with each other well I disagree that we've run over time because I need to catch the flight home okay with that I think us will wrap it up here so I just want to thank our panelists please give them a big round of applause