I know that Zeppelin is very good at interactively plotting something out of dataframes, like pie charts, histograms, line graphs, etc.
But I'm not quite sure if it is any easier to visualize graph structures, than starting from the scratch. I have been very pleasant with Neo4J’s web interface which is embedded in its server. Using Zeppelin as the primary visualizer might overcomplicate things, as it will require configuring the whole Zeppelin distribution as a subproject of S2Graph. There would also be a lot more JVM processes to manage - one for the Zeppelin server and one interpreter process for every notebook. I’m not trying to be NIH or anything, but looking at Neo4J, Apache spark and RethinkDB’s embedded web UI, I think it will be a nicer to think about the UI from the scratch - it could be the best selling point of s2graph. Best, Jong Wook > On Apr 12, 2016, at 6:08 AM, Alexander Bezzubov <b...@apache.org> wrote: > > Sounds as a great plan to me as well, thank you for sharing details, please > keep it up and keep the mailing list posted! > > As for "Query Graphical User Interface" I would suggest trying Zeppelin out > and just providing a an interpreter implementation [1] for the query > language you choose as it's very simple and nice GUI comes for free. > > 1. http://zeppelin.incubator.apache > .org/docs/0.6.0-incubating-SNAPSHOT/development/writingzeppelininterpreter > .html > > -- > Alex > > > On Tue, Apr 5, 2016 at 11:30 PM, Luke Han <luke...@gmail.com> wrote: > >> Hi Doyung and Jo, >> Actually, I have no concern about supporting more storages rather than >> HBase. Refactoring existing design to support more engines will make >> project more suitable for different usage. >> >> But the question here is the community does not know why, until you >> guys started to discuss in mailing list and reply above. Please keep moving >> on and bring more discussion in mailing list. >> >> Thanks. >> Luke >> >> >> >> Best Regards! >> --------------------- >> >> Luke Han >> >> On Fri, Apr 1, 2016 at 1:52 PM, Hyunsung Jo <hyunsung...@gmail.com> wrote: >> >>> Doyoung, >>> >>> Thank you for sharing the document! >>> >>> >>> Luke and Alexander, >>> >>> Do you have any concerns regarding supporting multiple storage engines? >>> >>> As far as I understand, although S2Graph began exclusively on top of >> HBase, >>> it always had other storage engines in mind. >>> Perhaps this is somewhat unclear in the proposal, but I see hits of the >>> plan for additional storages in statements such as - >>> S2Graph <https://wiki.apache.org/incubator/S2Graph> provides a scalable >>> distributed graph database engine over *a key/value store such as HBase*. >>> This is also why some of the earliest JIRA tickets (S2GRAPH-1, 51) cover >>> this topic. (Now that I think of it, we should have had this discussion >>> prior to opening the tickets, but better late than never!) >>> Thanks to the recent refactoring (S2GRAPH-17) as Doyoung mentioned, I >> think >>> the latest storage-related code is abstract + general enough to try out >>> integrations with storages other than HBase. >>> >>> Thanks, >>> Jo >>> >>> On Fri, Mar 25, 2016 at 11:06 PM DO YUNG YOON <sho...@gmail.com> wrote: >>> >>>> Hi Luke and Alexander. >>>> >>>> Thanks for asking question and here is reason I did list storage >> engine. >>>> >>>> S2Graph has been used HBase as primary storage engine. I think there is >>> no >>>> reason we need to change this. >>>> >>>> However, I also think there is no reason we should only support HBase. >>>> >>>> We realized that lots of codes can be independent to storage backend, >> so >>> we >>>> abstract away storage dependent codes at S2GRAPH-17. after this >>>> refactoring, it becomes easy for others who want to use different >> storage >>>> other than HBase to connect to their choice for storage. >>>> >>>> Personally I think it would be better to give user more options. >>>> >>>> For example, http://thinkaurelius.github.io/titan/ support various >>>> storages(Cassandra, HBase, BerkeleyDB, but seems primary is Casssandra) >>> and >>>> I think S2Graph can also support these options, but primary is HBase. >>>> >>>> What others think about this? >>>> >>>> Also regarding Query Graphical User Interface, I have no idea what >> other >>>> existing project can be used. If it is possible to re-use existing >>>> projects, then I prefer to use them. >>>> >>>> Please guide me what are these existing projects(I would love to try >>>> Zeppelin though). >>>> >>>> Thanks. >>>> Doyung Yoon >>>> >>>> On Thu, Mar 24, 2016 at 8:54 AM Luke Han <luke...@gmail.com> wrote: >>>> >>>>> Hi >>>>> For Storage Engines, are we trying to extend to others rather >> than >>>>> HBase? >>>>> >>>>> Thanks. >>>>> Luke >>>>> >>>>> >>>>> Best Regards! >>>>> --------------------- >>>>> >>>>> Luke Han >>>>> >>>>> On Wed, Mar 23, 2016 at 10:31 PM, Kim, Min-Seok <mskim....@gmail.com >>> >>>>> wrote: >>>>> >>>>>> updated and added >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> Batch Jobs(S2Lambda) >>>>>> - >>>>>> >>>>>> Kafka to HDFS (WAL) >>>>>> - >>>>>> >>>>>> Streaming Cooccurrence across labels(user-user/item-item >>>>> similarity) >>>>>> - >>>>>> >>>>>> OLAP operations on (WAL or KAFKA) >>>>>> - >>>>>> >>>>>> A/B Testing capabilities >>>>>> - Multi-armed Bandit to select the best query >>>>>> >>>>>> >>>>>> I think A/B and MAB can be component themselves, they could be >> merged >>>>> into >>>>>> other components. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2016년 3월 22일 (화) 오전 7:57, DO YUNG YOON <sho...@gmail.com>님이 작성: >>>>>> >>>>>>> Hi folks. >>>>>>> >>>>>>> I just want to open up discussion on our project roadmap. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://docs.google.com/document/d/1QSEf628QHrLmky16cJN_wIv0H_cfi1E9NGLqKMpdsNE/edit?usp=sharing >>>>>>> >>>>>>> >>>>>>> Things I wrote on link is completely draft(I just list up all I >> can >>>>> think >>>>>>> of now), please feel free to change as it is necessary. >>>>>>> Some of them might easy and some of them would take time, so I >> also >>>>> want >>>>>> to >>>>>>> ask what others think about first release. >>>>>>> Personally, I think It would be great if we can list up our load >>> map, >>>>>> then >>>>>>> decide priority, and talks about our first release. >>>>>>> Also, I think once we decide road map, then this road map can be >>> used >>>>> as >>>>>>> component at JIRA. currently there is no component so it is hard >> to >>>>> guess >>>>>>> what each issue is about. >>>>>>> >>>>>>> Looking forward to hear what others think. >>>>>>> >>>>>> >>>>> >>>> >>> >>
