The big advantage that this:
SELECT ?x ?y WHERE { ?x knows ?y . ?x name "marko" . }
Has over this:
g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
Is that the SPARQL query engine can pick which graph pattern to run first,
depending on the cardinalities in the graph - i.e. if there are many more
"knows" relationships than there are elements with name="marko" then it
makes sense to run (?x name "marko") first and then run (?x knows ?y) with
?x bound. And if there are many more elements with name="marko" than there
are "knows" relationships then the query engine can choose to run the query
in the opposite order. Declarative query language + cardinality-driven
query optimization = better scalability / performance.
Please correct me if I'm wrong but the gremlin traversal example will
always run in the order presented (imperative). I know there is a
MatchStep now in TP3 that could be used to do what I'm describing above,
but does that win the "easy to read" contest?
-Mike
On Tue, Nov 3, 2015 at 2:18 PM, Rob Vesse <[email protected]> wrote:
> You're overcomplicating the SPARQL example here
>
> SELECT ?x ?y WHERE { ?x knows ?y . ?x name "marko" . }
>
> No need for FILTER in this example
>
> Rob
>
>
>
> On 02/11/2015 10:24, "Marko Rodriguez" <[email protected]> wrote:
>
> >Hi,
> >
> >> Gremlin, based on my experience, is a barrier for many people who fall
> >>into
> >> category 1 (and even 2 at times).
> >
> >With TinkerPop3, I don't see that argument holding anymore. There has
> >always been this notion in the zeitgeist that Gremlin is "hard to read."
> >However, when Gremlin3 is compared to Cypher/SQL/SPARL, I don't see it
> >anymore. Look at the "side-by-side" representations dispersed throughout
> >https://news.ycombinator.com/item?id=10434372. With the
> >match()/where()/select()-clauses in Gremlin3, the "SQL"-vibe is there and
> >I don't see it as being all that complicated (of course I'm not the
> >person to judge this), moreover, its more "embedded" in the language than
> >either Cypher/SPARQL/SQL. For instance:
> >
> > SELECT ?x, ?y WHERE { ?x knows ?y . ?x name ?z . FILTER(?z ==
> "marko" } }
> > SELECT x,y FROM table WHERE x.knows.y AND x.name="marko" //
> shorthand
> > MATCH (x)-[:knows]->(y) WHERE x.name = "marko" RETURN x,y
> >
> >
> g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
> >
> >With Gremlin you don't need this "external" WHERE/FILTER notion. Its part
> >of the walk.
> >
> >Anywho…rambling…
> >
> >Marko.
> >
> >http://markorodriguez.com
> >
> >>
> >> On Wed, Oct 28, 2015 at 9:51 AM, Alaa Mahmoud <[email protected]>
> >>wrote:
> >>
> >>> I was at GraphConnect last week and I attended a Cypher training
> >>>session
> >>> (just for the heck of it :-)) I was amazed how easy it was to pick up
> >>>in a
> >>> short amount of time. I believe Cypher's Match/Where/Return syntax is a
> >>> good starting point for those coming from an RDBMS/SQL background and
> >>> there's a lot of those.
> >>>
> >>> Implementing a Cypher driver could make it easier for those with SQL to
> >>> move or at consider graph as a option.
> >>>
> >>> Regards
> >>> Alaa
> >>>
> >>> On Tue, Oct 27, 2015 at 3:05 PM, Ran Magen <[email protected]> wrote:
> >>>
> >>>> Hey Marko,
> >>>>
> >>>> Gremlin is definitely the best over-all "GQL" around. That's why I
> >>>>think
> >>>> that before we develop any language-driver, we need to ask ourselves
> >>>>if
> >>>> there's are any use-cases in which that language would be a better
> >>>>choice
> >>>> than gremlin.
> >>>>
> >>>> - SPARQL - Many people are familiar with SPARQL, so a driver would
> >>> help
> >>>> them easily get to work with a TP graph.
> >>>> - GraphQL - QBE is a great definition. The cool thing about these
> >>>> queries is that they're very "composable", which is perfect for a
> >>>> composite
> >>>> application in which you have deeply nested components, each
> >>> specifying
> >>>> its own sub-query (e.g. the standard practice in React UIs). Granted
> >>>> gremlin is much more powerful, and I'd use it in almost all
> >>>> applications,
> >>>> but when building something like a React application, GraphQL could
> >>>> come on
> >>>> top.
> >>>> - OpenCypher - While it's an over-all more "able" language than
> >>> SPARQL &
> >>>> GraphQL, I haven't seen any use-case in which it trumps gremlin.
> >>> That's
> >>>> why
> >>>> IMO there is no point in implementing it.
> >>>>
> >>>> My 2 cents.
> >>>> Cheers,
> >>>> Ran
> >>>>
> >>>>
> >>>> On Tue, 27 Oct 2015 at 02:37 Marko Rodriguez <[email protected]>
> >>> wrote:
> >>>>
> >>>>> Hi Ran,
> >>>>>
> >>>>> Here are my thoughts on GraphQL now that I have learned more about
> >>>>>it.
> >>>>>
> >>>>> 1. Matt Frantz and David Robinson nailed it -- its not really
> >>>>>a
> >>>>> "graph language." Its more a QBE (query by example -- first time I
> >>> heard
> >>>>> that was from Matt).
> >>>>> - As such, do we want to support it in TinkerPop when
> >>> we
> >>>>> can do much more complex queries with the Gremlin machine?
> >>>>> 2. I think we should try and get the GraphQL guys to implement
> >>> a
> >>>>> compiler for Gremlin VM.
> >>>>> - You said it -- providers have to implement a server
> >>> to
> >>>>> execute it. Why not just implement graph.structure API and let the
> >>>> Gremlin
> >>>>> VM do the work for you.
> >>>>> - Is this a Facebook thing? Perhaps someone can find
> >>>> their
> >>>>> repository and post a ticket and see where it goes.
> >>>>>
> >>>>> The one thing that GraphQL has going for it (like SPARQL) is the ease
> >>> of
> >>>>> the development/maintenance of the compiler. Cypher and SQL are going
> >>> to
> >>>> be
> >>>>> insanely complex compilers to implement/maintain -- it will take
> >>>> manpower.
> >>>>>
> >>>>> Marko.
> >>>>>
> >>>>> http://markorodriguez.com
> >>>>>
> >>>>> On Oct 26, 2015, at 11:49 AM, Ran Magen <[email protected]> wrote:
> >>>>>
> >>>>>> I'd be much more interested in GraphQL support.
> >>>>>> The cool thing about GraphQL is that you can easily create a unified
> >>>>> "graph
> >>>>>> query" from different components in an application, while keeping
> >>>>>>the
> >>>>>> separation between the components. It's a great feature for
> >>>>>>composite
> >>>>> UIs (e.g.
> >>>>>> React).
> >>>>>> As I understand it, GraphQL is mostly a standard for graph queries,
> >>> but
> >>>>> the
> >>>>>> user has to implement a server to actually execute the queries. And
> >>>> what
> >>>>>> better execution engine than the Gremlin VM?
> >>>>>>
> >>>>>> On Mon, 26 Oct 2015 at 15:17 Marko Rodriguez <[email protected]>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hey,
> >>>>>>>
> >>>>>>> After reading Stephen's reply, I was like -- "huh, sure." I didn't
> >>>>> really
> >>>>>>> don't care one way or another until I just read this:
> >>>>>>>
> >>>>>>> http://neo4j.com/blog/open-cypher-sql-for-graphs/
> >>>>>>>
> >>>>>>> Look at the tone and lies that Neo4j is portraying.
> >>>>>>>
> >>>>>>> * Marko Rodriguez as "just some buddy of Emil's."
> >>>>>>> * Aurelius is some company. No, its called DataStax.
> >>>>>>> * Not once is Apache TinkerPop discussed or referenced --
> >>> "just
> >>>>>>> Marko and a band of merry 'graphistas'."?!
> >>>>>>> * DataStax is NOT involved in their efforts for OpenCypher.
> >>>>>>>
> >>>>>>> The problem with Neo4j is they are corrupt. They use lies to
> >>>>>>>control
> >>>> the
> >>>>>>> population. If we support Cypher in TinkerPop (like actively put it
> >>>> into
> >>>>>>> the repository as a distribution) we will see press releases like:
> >>>>>>>
> >>>>>>> * TinkerPop drops Gremlin in favor of Cypher.
> >>>>>>> * TinkerPop realizes that Cypher is the superior language.
> >>>>>>> * TinkerPop follows Neo4j in learning how to do graph
> >>>> processing
> >>>>>>> the right way.
> >>>>>>> * etc.
> >>>>>>>
> >>>>>>> Its going to be a bunch malarky like that that I don't want
> >>>> surrounding
> >>>>>>> our project. It would behoove us to be smart about how we interact
> >>>> with
> >>>>>>> people like this as they will use every opportunity they can to
> >>>> destroy
> >>>>> our
> >>>>>>> project to better their economic efforts.
> >>>>>>>
> >>>>>>> I don't do lies nor interact with people who use misinformation and
> >>>>>>> deception to get "ahead,"
> >>>>>>> Marko.
> >>>>>>>
> >>>>>>> http://markorodriguez.com
> >>>>>>>
> >>>>>>> On Oct 26, 2015, at 4:35 AM, Stephen Mallette <
> [email protected]
> >>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I'd be open to have cypher and sparql as first class citizens of
> >>> The
> >>>>>>>> TinkerPop. As I see it, there are two groups of graph users on the
> >>>>> fringe
> >>>>>>>> of TinkerPop and they live in the cypher world and in the RDF
> >>> world.
> >>>>>>>> Having both of these projects in TinkerPop would allow us to reach
> >>>> both
> >>>>>>> of
> >>>>>>>> those communities. Doing so would help to expand usage and
> >>>> potentially
> >>>>>>>> attract more committers.
> >>>>>>>>
> >>>>>>>> On Fri, Oct 23, 2015 at 1:08 PM, Marko Rodriguez <
> >>>> [email protected]
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I (personally) am interested in getting another language into
> >>>>>>> TinkerPop's
> >>>>>>>>> distribution. I see an imbalance in the following table:
> >>>>>>>>>
> >>>>>>>>> TinkerGraph | Gremlin-Java8
> >>>>>>>>> Neo4j | Gremlin-Groovy
> >>>>>>>>> Hadoop | NOTHING
> >>>>>>>>>
> >>>>>>>>> That is, we have 3 graph distributions, why not have 3 language
> >>>>>>>>> distributions. Moreover, I don't want yet another Gremlin-JVMLang
> >>>>>>> language
> >>>>>>>>> as that doesn't showcase the virtual machine aspects of Gremlin
> >>>>>>>>>as
> >>>>> well
> >>>>>>> as,
> >>>>>>>>> for example: SPARQL-Gremlin or SQL-Gremlin.
> >>>>>>>>>
> >>>>>>>>> I (personally) am NOT interested in openCypher as the 3rd
> >>>>>>>>>language
> >>>>>>>>> distribution for the following 2 reasons:
> >>>>>>>>>
> >>>>>>>>> 1. It will be at least a year+ before it culminates into
> >>>>>>> something.
> >>>>>>>>> 2. It doesn't fold a different computing space into
> >>> TinkerPop.
> >>>>>>>>>
> >>>>>>>>> To expand on #2, Hadoop is NOT typically seen as a graph system,
> >>> but
> >>>>>>> with
> >>>>>>>>> TinkerPop, we have Hadoop serving as a graph engine. With SPARQL,
> >>> we
> >>>>>>> pull
> >>>>>>>>> in the RDF guys (thats cool). With SQL, we pull in the world. I
> >>>> sorta
> >>>>>>>>> prefer SPARQL as its an easy language to handle (thanks in part
> >>>>>>>>>to
> >>>>>>> Apache
> >>>>>>>>> Jena). With SQL we have Apache Calcite offering help, but SQL is
> >>>>> nasty
> >>>>>>>>> looking for graph queries and is just suuuuuch a beast of a
> >>> language
> >>>>>>> that
> >>>>>>>>> it would need someone dedicated to its maintenance/evolution.
> >>>>>>>>>
> >>>>>>>>> Anywho -- thats what I think about another language in TinkerPop.
> >>>> I'm
> >>>>>>> pro
> >>>>>>>>> SPARQL-Gremlin if it matures and people are excited about it.
> >>>>>>>>> https://github.com/dkuppitz/sparql-gremlin
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Marko.
> >>>>>>>>>
> >>>>>>>>> http://markorodriguez.com
> >>>>>>>>>
> >>>>>>>>> On Oct 23, 2015, at 10:45 AM, pieter-gmail <
> >>> [email protected]
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Is a opencypher <
> >>> http://neo4j.com/blog/open-cypher-sql-for-graphs/
> >>>>>
> >>>>> ->
> >>>>>>>>>> gremlin compiler something the tinkerpop team would consider
> >>>>>>>>> implementing?
> >>>>>>>>>> Perhaps, hopefully with help from neo4j themselves.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Pieter
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
>
>
>
>
>
