Hi everyone, I would like to reboot the conversation around TinkerPop 4, specifically as it concerns the structure API. You will have seen my posts, ever since my presentation [1] last January, about an algebraic approach to property graph schemas and transformations, which Ryan and I formalized in the APG paper [2]. I am now very close to releasing the Haskell implementation of this framework as open source software (to be accompanied by an Uber Engineering Blog post, in the next few weeks if all goes well).
At various times and places, I have suggested that we develop a Scala-based structure API for TP4 which implements APG in an extensible way. I think it is time to proceed and start committing code, or discuss alternative plans for the structure API. There seems to be plenty of community interest, and I now have an official OK to put some engineering hours towards it at work. I would like to align with you -- the TP PMC and other TinkerPop committers and developers -- on how to proceed, who will contribute, and what the development timeline will look like. Some specifics from my side: - Graph.Features will carry over into TP4; it will just be a bit more sophisticated than the current TP3 Graph.Features. Btw. I also proposed this idea of a graph feature vector at the recent Dagstuhl Seminar [3], where it caught on and will be the basis of a "dragon data model" that might help to keep TinkerPop aligned with upcoming standards like RDF* and GQL. - I feel we should use Scala for the API. This opinion is informed by my experiences writing tools of this kind in both Java and Haskell at Uber. While I am a huge fan of Haskell, practical considerations rule it out as an option. We need the API to be JVM-compatible. The best Haskell-JVM bridge in is Eta [4], but IMO it is not ready to be put in the critical path on a project such as TinkerPop; we used it at Uber for a while and found it to be a time sink, despite the generated bytecode working great. Likewise, I would strongly advise against continuing with a pure Java-based API if we want to do intelligent things with graph schemas. The language is just not appropriate as a basis for the type system in question. Scala, on the other hand, has all of the advantages of Haskell in terms of type safety and functional pattern matching, although it requires some extra discipline to keep your code pure. - Interoperability with Ryan's CQL (categorical query language [5]) is of interest. - Interoperability with mm-ADT should be straightforward now that mm-ADT has support for union types. Hopefully, mm-ADT's type system will end up as a proper superset of TP4's. Thoughts? Josh [1] https://www.slideshare.net/joshsh/a-graph-is-a-graph-is-a-graph-equivalence-transformation-and-composition-of-graph-data-models-129403012 [2] https://arxiv.org/abs/1909.04881 [3] https://www.dagstuhl.de/en/program/calendar/semhp/?semnr=19491 [4] https://eta-lang.org [5] https://www.categoricaldata.net
