I've had some thoughts on this thread since December. Since sparql-gremlin has a pretty long to-do list and there is likely a lot of discussion required on this list prior to it being ready for merge to a release branch, it seems like we might treat this as a normal feature under development. I think we should just merge it to a development branch in the TinkerPop repository and then collaborate on it from there. We've taken similar approaches with other "long term" pull requests which has allowed the code to develop as it would typically would. I'm thinking that's a better approach than a "big-bang" pull request.
Harsh, if that's ok with you, feel free to issue your PR against master and I'll get it setup against a development branch on our end (no rush, please give it a few days to see if everyone is ok with that approach). On Mon, Dec 18, 2017 at 5:16 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > > Should I also remove the northwind file? > > I think I'd prefer to see all of our sparql examples use the existing toy > graphs - better not to add more options - so I'd remove it as well. If > anyone disagrees, I don't really feel too strongly about not including it, > but it would be good to hear some reasoning as to why the existing datasets > that we already package are insufficient for users to learn with. > > > will need some help (quite possibly) with getting things right as far > as the DSL pattern for the gremlin language variants is concerned. > > We can help point you in the right direction when you get stuck or need to > clarify things. If you get really stuck, we can move to step 2 and have you > issue a PR sooner than later and we'll just merge what you have to a > development branch so others can collaborate with you on it more easily. > Let's see how things develop. > > > Also, since you are very well versed in the test suite, I would also > request some assistance for the same when we are there :) as it is our > first time pushing a work to the production level. So bear with us :) > > no worries. i will need to think on the testing approach. my thinking will > be focused on what i would call integration tests i.e. tests that evaluate > sparql-gremlin across the entire stack. I don't imagine that you need my > input to write some unit tests to validate the workings of your current > code though. > > > One question, though there is not a strict deadline, when is the 3.3.2 > release planned? > > We have no timeline on 3.3.2 at this point (we are just in the process of > releasing 3.3.1 so it will be a while before we see 3.3.2). I think the > merging of gremlin-javascript will likely trigger that release, i would > guess no earlier than February 2018 if all goes right with that. I also > don't mean to make it sound like sparql-gremlin needs to be part of that > release, so if it's not ready then, it's not ready and it releases with > 3.3.3. You'll find that with TinkerPop, we tend to release when software is > "ready" and not by setting long range time deadlines for ourselves. So, > don't worry about when we release sparql-gremlin too much. Let's stay > focused on just getting the code right. > > Thanks for your understanding. > > > > > On Mon, Dec 18, 2017 at 5:01 PM, Harsh Thakkar <hars...@gmail.com> wrote: > >> Hello Stephen, >> >> Alright, I will remove the bsbm file from the repository and I refer to >> it in the docs (with some examples) sharing a link to download from the >> website if that is acceptable. No worries. >> Should I also remove the northwind file? >> >> >> Your expectations are reasonable, it was just that I wasn't very clear >> about what needs to be done. Now it is pretty much clear. It will take some >> time for me to wrap my head around the specifics of the tinkerpop codebase >> in order to satisfy the 3 requirements. I will need some help (quite >> possibly) with getting things right as far as the DSL pattern for the >> gremlin language variants is concerned. I am already reading the dev-docs >> on this, from here: >> http://tinkerpop.apache.org/docs/current/reference/#dsl >> >> Also, since you are very well versed in the test suite, I would also >> request some assistance for the same when we are there :) as it is our >> first time pushing a work to the production level. So bear with us :) >> >> I agree with you on not having any API shifts, this does certainly not >> give a good impression, also its a lot of effort down the drain. Quality >> must be ensured. >> >> One question, though there is not a strict deadline, when is the 3.3.2 >> release planned? >> >> Cheers, >> Harsh >> >> >> On 2017-12-18 20:48, Stephen Mallette <spmalle...@gmail.com> wrote: >> > A quick note about (4) - Having some sample data for user convenience is >> > good. Files like that though should not be "resources", but should be >> added >> > here: >> > >> > https://github.com/harsh9t/tinkerpop/tree/master/data >> > >> > Placing those files there will allow them to be included in the the .zip >> > distribution files we produce for Gremlin Console and Gremlin Server. >> Now, >> > that BSBM file is a bit much. It's 90M in size and 22M compressed to >> zip. >> > Either way, that's going to push our already large zip distributions >> bigger >> > than they should be. I don't think the value of this file is worth the >> > that. We can definitely make it available as a separate download from >> the >> > web site if everyone thinks it's that important and then provide links >> to >> > it, but I don't think it should be in the source repository as it is >> now. >> > >> > Aside from (4) I just wanted to make some general points about my >> > expectations for a sparql-gremlin being part of a TinkerPop release >> branch. >> > Apologies if this wasn't clear from when we started. I think we need to >> see >> > sparql-gremlin as close to a final form as possible before we look to >> merge >> > it. By "final" I mean: >> > >> > 1. sparql-gremlin has a full test suite - that means good unit test >> > coverage at a minimum and integration tests as necessary (and I sense >> they >> > will be necessary). I agree with marko, that we also have to consider >> the >> > testing pattern carefully, so that we set the stage properly for future >> > languages. >> > 2. sparql-gremlin has a clear and easy method of usage that is >> consistent >> > with how TinkerPop works - this is crucial prior to merge because >> TinkerPop >> > has high profile production usage. once merged sparql-gremlin will >> > immediately be consumed by users and we will not want to shift that API >> > once it is available. we will break the code of too many people if we do >> > that. we need to strive to get this right from the start. >> > 3. sparql-gremlin has a good body of user documentation. >> > >> > I don't think any of this is insurmountable, but it does mean there is a >> > fair bit of work to do and it won't happen overnight. We held >> > gremlin-dotnet to the same rigorous level before merging and even >> > gremlin-javascript all these months later is still not merged for >> basically >> > the same reasons, so this is just the process that we tend to go >> through. >> > If we follow what we did for the GLVs, we will likely follow this basic >> > process: >> > >> > 1. You get sparql-gremlin "pretty close" to final in your fork >> > 2. Once we all agree that you are "pretty close", you offer the pull >> request >> > 3. We merge it into a TinkerPop branch for further evaluation (this >> will be >> > a development branch and not a release branch) >> > 4. We work together to get the development branch "final" >> > 5. We issue a pull request from that development branch >> > 6. The pull request goes through the standard review/vote process and we >> > merge to a release branch. >> > 7. sparql-gremlin will likely be part of 3.3.2 release >> > >> > I hope that make sense. >> > >> > >> > On Mon, Dec 18, 2017 at 12:26 PM, Marko Rodriguez <okramma...@gmail.com >> > >> > wrote: >> > >> > > Actually, my (3) is bad. Given that query() would always return a >> > > Traversal<S, Map<String,E>>, it would be necessary to have that >> linearized >> > > to Traversal<Vertex,Vertex> for the test suite to validate it. That >> would >> > > mean making SPARQLTraversal support extended Traversal methods like >> > > flatMap(), blah, blah… That seems excessive, though convenient. >> > > >> > > Hm…… Thoughts?, >> > > Marko. >> > > >> > > http://markorodriguez.com >> > > >> > > >> > > >> > > > On Dec 18, 2017, at 9:21 AM, Marko Rodriguez <okramma...@gmail.com> >> > > wrote: >> > > > >> > > > Hello, >> > > > >> > > > A couple of items worth considering. >> > > > >> > > > Regarding (7), that should be done prior to master/ merge. It is >> > > necessary to follow the patterns that are established in TinkerPop >> > > regarding language interoperability. The DSL pattern developed for >> Gremlin >> > > language variants seems to be the best pattern for distinct languages >> as >> > > well. In essence, if your language is not a fluent language, and >> instead, >> > > uses a String, then it should be wrapped as such in a fluent interface >> > > using all the Strategy, Step, and Traversal methods that makes sense >> so it >> > > works within the larger infrastructure of TinkerPop (e.g. testing! — >> see >> > > below). What I proposed in my previous email seems the easiest and >> cleanest >> > > way to do things. >> > > > >> > > > Regarding (3), testing is crucial. Given that this would be >> TinkerPop’s >> > > first distinct language, we don’t have a pattern set forth for >> testing. >> > > However, this doesn’t mean we can’t improvise on our current model. >> Off the >> > > top of my head, perhaps the best way would be to follow the >> > > ProcessTestSuite and do the SPARQL variants of those. For instance: >> > > > >> > > > https://github.com/apache/tinkerpop/blob/master/gremlin- >> > > test/src/main/java/org/apache/tinkerpop/gremlin/process/ >> > > traversal/step/map/VertexTest.java#L62 <https://github.com/apache/ >> > > tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/ >> > > tinkerpop/gremlin/process/traversal/step/map/VertexTest.java#L62> >> > > > >> > > > The SPARQL test version would be: >> > > > >> > > > @Override >> > > > public Traversal<Vertex, Vertex> get_g_VX1X_out(final Object v1Id) { >> > > > return sparql.query(“SELECT ?x WHERE {“ + toURI(v1Id) + “ ?a ?x >> }”); >> > > > } >> > > > >> > > > In this way, sparql is your SPARQLTraversalSource for each test and >> > > query() will return a Traversal typed according (query() will have to >> have >> > > solid generic support). From there, you would implement each and >> every test >> > > that is semantically possible with SPARQL (where SPARQ won’t be able >> to >> > > semantically cover all Gremlin tests). >> > > > >> > > > Stephen has done a lot of recent work to generalize our test suite >> out >> > > of Java so it is in a language agnostic form. I haven’t been >> following that >> > > work so I’m not sure what I’m am saying above is exactly as it should >> be >> > > done, but it is a start. >> > > > >> > > > HTH, >> > > > Marko. >> > > > >> > > > http://markorodriguez.com <http://markorodriguez.com/> >> > > > >> > > > >> > > > >> > > >> On Dec 18, 2017, at 7:43 AM, Harsh Thakkar <hars...@gmail.com >> <mailto: >> > > hars...@gmail.com>> wrote: >> > > >> >> > > >> Hi Stephen and All, >> > > >> >> > > >> Thanks for going through the code. I address your questions below >> (in >> > > the same order): >> > > >> >> > > >> 1. Yes, this file can be removed. It was just to test the traversal >> > > method. >> > > >> >> > > >> 2. Yes, I have commented out the block of tests at this moment >> since we >> > > do not need to run tests at mvn clean install time. However, I kept >> it (in >> > > commented out form) if there arose a need in future for the same. It >> can >> > > surely be removed if you think, it won't be necessary. >> > > >> >> > > >> 3. There were two testing units (we continued them from Daniel's >> > > version), one to check whether the prefixes are being encoded >> correctly, >> > > the second one is to test whether the generated traversal is correct >> (in >> > > short the compiler is functioning as it should). Since, we extended >> > > previous work supporting a variety of SPARQL operators, more test >> cases can >> > > be added to validate that each of these is functioning as expected. >> > > However, as I mentioned in point #2. we need not do it explicitly as >> we >> > > (Dharmen and I) have already tested them on 3-4 different datasets and >> > > query-sets. Now, since we did not know if that was going to be >> formally >> > > required in the future or not, we left them as it is, just commented >> it out. >> > > >> >> > > >> 4. These resources are the graphml files that we wish to provide >> the >> > > users, for (i) loading and querying famous datasets - the Berlin >> SPARQL >> > > Benchmark (BSBM) (famous in the Semantic Web-RDF community) so that >> they >> > > do not have to look elsewhere for the same. (ii) Also, it provides a >> strong >> > > use-case for demonstrating the applicability of sparql-gremlin >> (creates >> > > trust in the SW community users) and (iii) to keep the plug-in pretty >> much >> > > self-dependent. >> > > >> >> > > >> 5 & 6 YES, damn it. The IDE did this. I will revert these changes. >> > > It's like when you are not looking, the IDE does things on it own :-/ >> > > apologies! >> > > >> >> > > >> 7. Regarding, Marko's thoughts -- Yes, I was waiting for you to >> reply >> > > to the thread. I do have some thoughts on this. But first, I was >> wondering >> > > if this (what Marko suggested) is supposed to be entirely implemented >> in >> > > the current version of sparql-gremlin 0.2, i.e. including the >> > > withStrategies() and withStrategies() and remote() features, or it is >> to be >> > > supported eventually (after the sparql-gremlin 0.2.0) plugin is >> rolled out. >> > > Also, I am not entirely sure I got what Marko was exactly suggesting. >> I >> > > bring this to light in the in-line style reply to Marko's comment >> later >> > > here. >> > > >> >> > > >> The current implementation is more of a typical compiler, the >> users, >> > > however, can use it by specifying the query file and the dataset >> against >> > > which it is to be executed via the command (once in the gremlin >> shell): >> > > >> >> > > >> gremlin> graph = TinkerGraph.open(..) >> > > >> gremlin> SparqlToGremlinCompiler.convertToGremlinTraversal(graph, >> > > "SELECT ?a WHERE {....} ") >> > > >> ==>{?x:marko, ?y:29} >> > > >> ==>{?x:josh, ?y:32} >> > > >> >> > > >> >> > > >> i.e. load a graph using pre-defined tinkerpop methods ( graph.io < >> > > http://graph.io/>(IoCore.gryo()).readGraph(graphName), >> > > TinkerGraph.open(), etc ) , then execute the traversal as above with >> > > arguments -- (graph, queryString), where queryString = "SPARQL query". >> > > >> >> > > >> Now Let me quote Marko's comment and reply in-line to bring more >> > > clarity: >> > > >> >> > > >> 1. There should be a SPARQLTraversalSource which supports one spawn >> > > method — query(String). >> > > >> This is already happening inside the code. Therefore, we do >> not >> > > need to mention it explicitly. Please correct me if I got it wrong >> here. >> > > >> >> > > >> 2. SPARQLTraversal is spawned and it only supports only the >> Traversal >> > > methods — next(), toList(), iterate(), etc. >> > > >> All traversal methods that are supported, available to a >> regular >> > > gremlin traversal, can be used by the sparql-gremlin compiler >> generated >> > > traversal as well. >> > > >> >> > > >> 3. query(String) adds a ConstantStep(String). >> > > >> This is happening internally (as shown in the example >> > > above), we can also make explicit. i.e. let the user only provide the >> > > queryString instead of the whole "SparqlToGremlinCompiler. >> > > convertToGremlinTraversal(graph, "SELECT ?a WHERE {....} ")" command. >> > > Does this make sense? or am I missing something here. >> > > >> >> > > >> >> > > >> 4. SPARQLTraversalSource has a registered SPARQLStrategy. >> > > >> At this moment, we leave it to the default setting for this >> > > strategy selection. >> > > >> >> > > >> 5. SPARQLTraversalSource should also support withStrategies(), >> > > withoutStrategies(), withRemote(), etc. >> > > >> Once the traversal is generated, it can support all strategies >> > > like any other gremlin traversal. Does this make sense to you? >> > > >> >> > > >> In a nutshell, >> > > >> What is happening is that we are converting the SPARQL queryString >> into >> > > a gremlin traversal and leave it upto the tinkerpop compiler to >> choose what >> > > is best for it. >> > > >> We only map a SPARQL query to its corresponding pattern matching >> > > gremlin traversal (i.e. using with .match() clause). Since, the >> > > expressibility of SPARQL is less than that of Gremlin (i.e. SPARQL 1.0 >> > > doesn't support/allow performing looping and traversing operations), >> we >> > > can only map what is in the scope of SPARQL language to Gremlin. Once >> the >> > > traversal is generated, it is left to the tinkerpop compiler to >> select and >> > > execute a wide range of strategies ( various levels of optimizations, >> et). >> > > >> >> > > >> NOTE - Also, Right now the sparql-gremlin compiler returns the >> > > traversal (string) and not Bytecode. Returning the Bytecode is also >> > > completely possible, if you want so. We can just perform >> > > traversal.asAdmin().getBytecode() for this and it is done. >> > > >> >> > > >> Since, we extended Daniel's work, we have not changed the names of >> > > classes, methods and variable which were used. This, however, can be >> > > changed, if you suggest so. >> > > >> >> > > >> 8. Yes, working in the academia doesn't groom you much on the >> > > importance of commenting in the code by default, or for that matter >> any >> > > "good-practices". I will add appropriate comment block in each class >> for >> > > the javadocs. >> > > >> >> > > >> I hope the above reply address your questions to quite some extent. >> > > Most of the issues are already handled internally (as I stated >> above). We >> > > can also leave some advanced features such as remote(), for the 0.2.1 >> > > release (though this is just an option) :D >> > > >> Having said that, Of course, we are in no hurry for the pull >> request. I >> > > also believe it makes complete sense to get things right. >> > > >> >> > > >> Cheers! >> > > >> >> > > >> On 2017-12-18 14:11, Stephen Mallette <spmalle...@gmail.com >> <mailto: >> > > spmalle...@gmail.com>> wrote: >> > > >>> Harsh, I looked at the code in a bit more detail than I have. >> Here's >> > > some >> > > >>> thoughts/questions I had as I was going through things: >> > > >>> >> > > >>> 1. Can this file be removed - it doesn't appear to have any usage >> that >> > > I >> > > >>> can see: >> > > >>> >> > > >>> https://github.com/harsh9t/tinkerpop/blob/master/sparql- >> > > gremlin/src/main/java/org/apache/tinkerpop/gremlin/sparql/Runable.java >> < >> > > https://github.com/harsh9t/tinkerpop/blob/master/sparql- >> > > gremlin/src/main/java/org/apache/tinkerpop/gremlin/sparql/ >> Runable.java> >> > > >>> >> > > >>> 2. I note that this entire block of tests is commented out - >> should >> > > that be >> > > >>> removed?: >> > > >>> >> > > >>> https://github.com/harsh9t/tinkerpop/blob/master/sparql- >> > > gremlin/src/test/java/org/apache/tinkerpop/gremlin/sparql/ >> > > SparqlToGremlinCompilerTest.java >> > > >>> >> > > >>> 3. I could be wrong, but even if you didn't remove the tests >> above, it >> > > >>> seems like unit testing is rather thin at this point. Am I missing >> > > >>> something? Is there more work to do there? >> > > >>> >> > > >>> 4. I don't understand the nature of these resources: >> > > >>> >> > > >>> https://github.com/harsh9t/tinkerpop/tree/master/sparql- >> > > gremlin/src/main/resources >> > > >>> >> > > >>> Is there any need to package those with the jar? Should those be >> "test" >> > > >>> resources instead? Do we need the really large data/bsbm1m.graphml >> > > file for >> > > >>> any specific reason? >> > > >>> >> > > >>> 5. What are these changes to these poms? >> > > >>> >> > > >>> https://github.com/harsh9t/tinkerpop/commit/ >> > > cb3b6512ea3536f556108e5a257c4586aa4d157a >> > > >>> >> > > >>> I assume that your IDE did that accidentally and it was not >> intended. >> > > >>> Please revert that change. >> > > >>> >> > > >>> 6. This looks odd too - gremlin-shaded repeated again and again >> and >> > > again: >> > > >>> >> > > >>> https://github.com/harsh9t/tinkerpop/commit/ >> > > 143d16f20dcaa9c915b96cdd4adf7b1504db5d36#diff- >> > > 9e90009f097eabeb25c28159571fc6a2R118 >> > > >>> >> > > >>> 7. Did you have any thoughts in reference to Marko's earlier >> reply that >> > > >>> described how sparql-gremlin should be used? Right now, it seems >> like >> > > the >> > > >>> code you have there is just the "engine" but lacks the piece that >> > > connects >> > > >>> it into the rest of the stack. From my perspective, I think we >> need to >> > > be >> > > >>> sure that users have an easy, clear and consistent way to use >> > > >>> sparql-gremlin before we can merge this work. Obviously, having >> that >> > > aspect >> > > >>> of the code thought through will impact the documentation that you >> > > write as >> > > >>> well, so I think you need to go down this path a bit further >> before we >> > > get >> > > >>> to the pull request stage. >> > > >>> >> > > >>> 8. We aren't big javadoc sticklers here, but we try to at least >> get >> > > class >> > > >>> level javadoc in place for most classes. I don't see much javadoc >> or >> > > >>> comments in the code right now. I think I'd like to see a modicum >> of >> > > >>> javadoc/comments present as part of this work. >> > > >>> >> > > >>> So, that's my broad level feedback at this point. It seems as >> though >> > > there >> > > >>> are some reasonably large issues there to contend with before a >> pull >> > > >>> request is worth issuing. That's not a problem, of course....we >> will >> > > just >> > > >>> keep iterating toward the goal. I'm not aware of anything that is >> > > pushing >> > > >>> us to rush to a pull request - I'm of the opinion that we can >> take the >> > > time >> > > >>> to get this right. >> > > >>> >> > > >>> Thanks, >> > > >>> >> > > >>> Stephen >> > > >>> >> > > >>> >> > > >>> On Fri, Dec 15, 2017 at 1:46 PM, Joshua Shinavier < >> j...@fortytwo.net> >> > > wrote: >> > > >>> >> > > >>>> Hi Marko, >> > > >>>> >> > > >>>> I think we're more or less on the same page here; it's clear >> that TP3 >> > > has a >> > > >>>> different API than TP2. If you look at the guts of TP3 GraphSail >> [1], >> > > it >> > > >>>> uses the modern APIs, and yet does adapt them to the Sail >> interface. >> > > >>>> >> > > >>>> Something like PropertyGraphSail (or an equivalent Jena thing) >> still >> > > makes >> > > >>>> sense in TP3, as well. One interesting detail here is that in >> TP3, >> > > vertices >> > > >>>> can have labels, which can be turned into rdf:type statements >> (that, >> > > in >> > > >>>> turn, can be used to enable subclass/superclass inheritance if >> the >> > > graph is >> > > >>>> combined with a RDF schema. >> > > >>>> >> > > >>>> A TP3 equivalent of SailGraph would indeed be quite different in >> > > >>>> implementation -- strategies, not wrapper graph -- than what we >> had >> > > for >> > > >>>> Blueprints, and yet would serve the same purpose. >> > > >>>> >> > > >>>> Josh >> > > >>>> >> > > >>>> >> > > >>>> [1] >> > > >>>> https://github.com/joshsh/graphsail/tree/master/src/ >> > > >>>> main/java/net/fortytwo/tpop/sail >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> On Fri, Dec 15, 2017 at 10:22 AM, Marko Rodriguez < >> > > okramma...@gmail.com> >> > > >>>> wrote: >> > > >>>> >> > > >>>>> Hello, >> > > >>>>> >> > > >>>>> The model proposed below is in-line with TinkerPop2’s way of >> > > thinking. >> > > >>>>> Unfortunately, TinkerPop3 and more so for TinkerPop4, the Graph >> > > >>>> “structure" >> > > >>>>> API will become deprecated. This means that the notion of >> > > “wrapping the >> > > >>>>> Graph API†has gone away for TP3 and will be completely gone >> in >> > > TP4. In >> > > >>>>> TP4, there will not even be a Graph API — no more Vertex, >> Edge, >> > > Property, >> > > >>>>> etc. Only the concept of a Graph with only methods like >> > > >>>> Graph.traversal(), >> > > >>>>> Graph.partitions(), etc. >> > > >>>>> >> > > >>>>> Why was this route taken? In TinkerPop3, there was a need to >> support >> > > any >> > > >>>>> language besides Java. This was why Gremlin bytecode and the >> concept >> > > of >> > > >>>> the >> > > >>>>> Gremlin traversal machine was introduced. A provider simply gets >> > > Gremlin >> > > >>>>> bytecode and has to do something with it. For the Java-based >> Gremlin >> > > >>>>> traversal machine, this is why providers implement their own >> > > GraphStep, >> > > >>>>> VertexStep, etc. For a Python-based Gremlin traversal machine, >> > > likewise… >> > > >>>>> >> > > >>>>> This means that SailGraph, GraphSail, PropertyGraphSail as >> stated >> > > below >> > > >>>>> don’t make sense in the current and future architectures. >> > > >>>>> >> > > >>>>> The next question becomes, "well how would you turn an RDF store >> > > into a >> > > >>>>> PropertyGraph?†Easy — implement your own custom GraphStep, >> > > VertexStep, >> > > >>>>> etc. and respective ProviderStrategies that will handle the >> bytecode >> > > >>>>> compilation accordingly. >> > > >>>>> >> > > >>>>> The next question becomes, “well how would a PropertyGraph >> support >> > > >>>>> reasoning?†Easy — implement your own custom >> DecorationStrategy >> > > that will >> > > >>>>> insert reasoning into the traversal giving the RDFS schema. For >> > > instance: >> > > >>>>> g.V().out(“likes†) >> > > >>>>> ==> >> > > >>>>> g.V().out(“knows†,†likes†) >> > > >>>>> iff “likes†is a sub-property of “knows†>> > > >>>>> >> > > >>>>> In essence, it is possible to do this integration of RDF and >> > > TinkerPop, >> > > >>>> it >> > > >>>>> just needs to be done at the correct level of abstraction so >> that it >> > > >>>> stays >> > > >>>>> in line with how TinkerPop is evolving, not how it was back in >> 2012. >> > > >>>>> >> > > >>>>> Take care, >> > > >>>>> Marko. >> > > >>>>> >> > > >>>>> http://markorodriguez <http://markorodriguez/>.com >> > > >>>>> >> > > >>>>> >> > > >>>>> On 2017-12-13 07:46, Joshua Shinavier <j...@fortytwo.net> >> wrote: >> > > >>>>>> Hi Harsh,> >> > > >>>>>> >> > > >>>>>> Glad you are taking Daniel's work forward. In porting the code >> to >> > > the> >> > > >>>>>> TinkerPop code base, might I suggest we allow for not only >> > > >>>>> SPARQL-Gremlin,> >> > > >>>>>> but a whole suite of RDF tools as in TP2. Perhaps call the >> module> >> > > >>>>>> rdf-gremlin. Then we could have all of:> >> > > >>>>>> >> > > >>>>>> * SPARQL-Gremlin: executes standard SPARQL queries over a >> Property >> > > >>>> Graph> >> > > >>>>>> database> >> > > >>>>>> * GraphSail [1,2]: stores RDF quads in the database, >> explicitly, >> > > and> >> > > >>>>>> enables SPARQL and triple pattern queries over the quads> >> > > >>>>>> * PropertyGraphSail [3]: exposes a Property Graph with of two >> > > mappings >> > > >>>>> to> >> > > >>>>>> the RDF data model> >> > > >>>>>> * SailGraph [4]: takes an RDF triple store (not natively >> supporting> >> > > >>>>>> Gremlin) and enables Gremlin queries> >> > > >>>>>> * others? I have often thought that a continuous SPARQL >> > > implementation> >> > > >>>>>> built on Gremlin would be powerful> >> > > >>>>>> >> > > >>>>>> The biggest mismatch between the TP2 suite and what might be >> built >> > > for> >> > > >>>>>> Apache TinkerPop is that the previous suite was implemented >> using >> > > >>>>> (Eclipse)> >> > > >>>>>> RDF4j, whereas things seem to be leaning towards (Apache) Jena >> now.> >> > > >>>>>> However, the same principles could be applied.> >> > > >>>>>> >> > > >>>>>> Josh> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> [1] https://github.com/tinkerpop/blueprints/wiki/Sail- >> > > Ouplementation> >> > > >>>>>> [2] https://github.com/joshsh/graphsail> >> > > >>>>>> [3]> >> > > >>>>>> https://github.com/tinkerpop/blueprints/wiki/PropertyGraphSa >> il- >> > > >>>>> Ouplementation> >> > > >>>>>> [4] https://github.com/tinkerpop/blueprints/wiki/Sail- >> > > Implementation >> > > >>>>> >> > > >>>>> http://markorodriguez.com >> > > > >> > > >> > > >> > >> > >
