On Mon, Apr 15, 2019 at 12:07 PM Marko Rodriguez <[email protected]> wrote:
> [...] > TinkerPop4 will have VM implementations on various language-platforms. For > sure, Apache’s distribution will have a JVM and .NET implementation. The > purpose of TinkerPop-specific types (and not JVM, Mono, Python, etc.) types > is that we know its the same type across all VMs. > I agree it is important to define a standard set of scalar types. They can probably be counted on one hand, or at most two -- at Uber, we use bytes and byte arrays, character strings, floats (varying precision and signedness), and integers (varying precision and signedness) as basic types. My point is that you may not need special, TinkerPop-specific wrapper classes for the scalar types; it is enough to define a mapping. E.g. Integer is a suitable implementation, on the JVM (dunno what the .NET equivalent is), for a standard 32-bit signed integer type, but a TInteger wouldn't hurt. > > To my mind, your approach is headed in the direction of a > > TinkerPop-specific notion of a *type*, in general, which captures the > > structure and constraints of a logical data type > > < > https://www.slideshare.net/joshsh/a-graph-is-a-graph-is-a-graph-equivalence-transformation-and-composition-of-graph-data-models-129403012/42 > < > https://www.slideshare.net/joshsh/a-graph-is-a-graph-is-a-graph-equivalence-transformation-and-composition-of-graph-data-models-129403012/42 > >>, > > and which can be used for query planning and optimization. These include > > both scalar types as well as vertex, edge, and property types, as well as > > more generic constructs such as optionals, lists, records. > > Yes — I’d like to be able to use some type of formal data type > specification. You have those skills. I don’t. My rudimentary > (non-categorical) representation is just “common useful data structures” — > map, list, bool, string, etc. > I think we can formalize an appropriate general-purpose data model along the lines I have motivated previously, with property graphs as a special case. You are on the thread with Ryan, where we are trying to connect the intuitive model with CQL. This would provide some nice guarantees of tractability, and think the relationship of the model with runtime types ought to be straightforward; they are basically just tuples with reference -- pairs, lists, etc. > A TList only supports primitives. However, a TRDFList could be a complex > type for dealing with RDF lists and would be contained with the TP4-VM. > Adding complex types is okay — it doesn’t break anything. > Agree, and don't care too much about the names of the runtime types. > Hm. Yea, I’m not too strong with hypergraph thinking. > > g.V(1) // vertex > g.V(1).outE(‘family’) // hyperedges > g.V(1).outE(‘family’).inV(‘father’) // ? perhaps inV/outV/bothV > can take a String… label? > > We should talk to the GRAKN.AI guys and see what they think. > https://grakn.ai/ <https://grakn.ai/> > https://dev.grakn.ai/docs/general/quickstart < > https://dev.grakn.ai/docs/general/quickstart> > Yes, I am a fan of GRAKN.AI's data model, and I think TinkerPop's structure APIs ought to be expressive enough to interface with it. The "projections" I have talked about here and elsewhere are "roles" in GRAKN, which relaxes the property graph constraint from two projections/roles per relationship to any number. GRAKN's relationships are hyper-edges in that sense, and also in the colloquial sense of "edges to/from edges", i.e. allowing projection between relationship types. Yes. I want to make sure we naturally/natively support property graphs, RDF > graphs, hypergraphs, tables, documents, etc. Property graphs (as specified > by Neo4j) are not “special” in TP4. Like Gremlin for languages, property > graphs sit side-by-side w/ other data structures. If we do this right, we > will be heros! > +1 Josh
