> > > *About the Authors*Ian Robinson is the co-author of REST in Practice > (O'Reilly Media, 2010). Ian is an engineer at Neo Technology, working on a > distributed version of the Neo4j database. Prior to joining the engineering > team, Ian served as Neo's Director of Customer Success, managing the > training, professional services, and support arms of Neo, and working with > customers to design and develop mission-critical graph database solutions. > Ian came to Neo Technology from ThoughtWorks, where he was SOA Practice > Lead and a member of the CTO's global Technical Advisory Board. Ian > presents frequently at conferences worldwide on topics including the > application of graph database technologies, and RESTful enterprise > integration.
Dr. Jim Webber is Chief Scientist with Neo Technology, where he researches > novel graph databases and writes open source software. Previously, Jim > spent time working with big graphs like the Web for building distributed > systems, which led him to being a co-author on the book REST in Practice > (O'Reilly Media, 2010). Jim is active in the development community, > presenting regularly around the world. His blog is located at > http://jimwebber.org and he tweets often @jimwebber. > Emil Eifrem is CEO of Neo Technology and co-founder of the Neo4j project. > Before founding Neo, he was the CTO of Windh AB, where he headed the > development of highly complex information architectures for Enterprise > Content Management Systems. Committed to sustainable open source, he guides > Neo along a balanced ... Not exactly an unbiased source. On Mon, Oct 26, 2015 at 11:58 AM, Stefán <[email protected]> wrote: > Hi, > > I would at least try to rely on definitions, sources and/or specs that are > not originated from a player in the field. > > There are many articles that discuss this and here is one: > https://www.safaribooksonline.com/library/view/graph-databases/9781449356255/ch01.html > > By stating this I'm not saying that Titan can not be fast and if you keep > in mind that graphs are hard to shard, mostly because of this principle, > then one could argue that using a column or key/value store underneath has > merit. (over simplification) > > Regards, > -Stefan > > > On Monday, 26 October 2015 15:38:08 UTC, Pieter Martin wrote: >> >> Hi, >> >> Here is link that addresses the topic from a different angle. >> >> >> http://thinkaurelius.com/2013/11/01/a-letter-regarding-native-graph-databases/ >> >> Admittedly it is from the architect of titan on top of cassandra which >> makes it perhaps more non native that other graph db's non nativeness. >> Its a rather slippery slope to start arguing about nativeness. >> >> Cheers >> Pieter >> >> On 26/10/2015 17:26, scott molinari wrote: >> > That makes perfect sense. So, theoretically, a "pure" graph database >> > with its own storage engine has intrinsic advantages over other graph >> > databases, which rely on third party storage engines. That is good to >> > know actually. >> > >> > Scott >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google >> > Groups "OrientDB" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to [email protected] >> > <mailto:[email protected]>. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
