> > > [...] > > 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.
just getting real specific around TLong/TInteger for a minute - should TinkerPop's primitive just be TNumber? We do a lot of "stuff" to try to make numbers just be numbers across TinkerPop and each language has to do extra stuff to match the JVM, which is something we keep trying to avoid. On Tue, Apr 16, 2019 at 12:34 PM Joshua Shinavier <[email protected]> wrote: > 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 >
