Hi, You ask, "are you thinking only about giving TP3 the ability to express the underlying datastore's schema" Yes and no. I am not thinking of giving tinkerpop any schema modification ability. Tinkerpop is afterall schemaless. However any tinkerpop graph does have a implicit schema. I'd almost rather call it a topology than a schema. A graphs topology is in many instances as interesting as the actual data. Seeing as every label travels though tinkerpop som e sexy PartitionStrategyStep could maintain this in the graph. I reckon this is achievable without any change to tinkerpop's interface or semantics.
Once the structure of this topology partition (topology of the topology) for tinkerpop is well established vendors can use it to do all sorts of peculiar things of which their are many. Clients can use it to interrogate (with gremlin ) the topology as part of their analysis of the graph. As an aside, the jdk's JDBC Connection has a method getMetaData(). In a similar way any tinkerpop graph would make its topology accessible via gremlin. My understanding is that to try to get a standardized schema definition language is not something tinkerpop is interested in, considering the diverse nature of the implementations. Right now the graph of the the product I am working has over 5000 distinct vertex labels and many more edge labels. Its a telco application importing networks for multiple vendors (Ericsson, Huawei, Zte, Alcatel...). On a graph with such a breadth the telco engineers spend almost as much time investigating the topology as they do the actual data. Cheers Pieter On 20/05/2015 22:12, Matt Frantz wrote: > When you say "tinkerpop auto capturing schema information," are you > thinking only about giving TP3 the ability to express the underlying > datastore's schema, or are you also considering allowing a vendor-agnostic > schema expression capability that could be used to configure the > datastore? I guess the "auto capturing" term makes me think of the use > case where the schema is encoded somewhere, and we want TP3 to import it, > rather than the complementary capability of allowing TP3 to become a schema > definition API. > > I'm in favor of providing the ability to express graph schema, since it > opens up many exciting possibilities, including the ones you mention, but > also support for user-defined types (UDT's). UDT's could be applied to > property values as well as to elements of the graph. > > All of the schema could be captured in a graph, much in the same way that > Java provides reflection via a specific set of classes. Schema access and > mutation operations could thus be expressed in Gremlin, must in the same > way that relational databases provide a set of tables that serves the same > purpose there. Vendors would provide (full or partial) implementations of > this API using existing extensibility mechanisms (e.g. strategies to apply > to schema traversals) plus new ones (e.g. a SchemaGraph API with a > canonical set of operations). > > On Wed, May 20, 2015 at 10:52 AM, pieter-gmail <[email protected]> > wrote: > >> Hi, >> >> This is to hear what the community thinks about tinkerpop auto capturing >> schema information. >> >> Since labels, any tinkerpop graph has a schema and seeing that tinkerpop >> captures every vertex and edge with its label it could transparently >> maintain this in the db itself. >> >> It should add little to no overhead to capturing data as schemas change >> seldom and are small compared to the actual data. >> >> There are may use cases for having the schema available as part of the >> regular graph. >> >> * Natural place to attach further (non tinkerpop) info like acl, audit >> rules, multiplicities, navigability >> * Might enable code insight for gremlin. >> * Store performance/analytic result. >> * Easy for new users to understand any graph's schema >> * Might facilitate gremlin optimization >> ... >> >> I understand that may implementations have their own peculiar schema >> requirements. However my idea is not to walk a path outside of tinkerpop's >> own semantics. >> >> Besides all that there is something sweet about a graph >> containing/managing its own meta data. >> >> Thanks >> Pieter >>
