> > > - VertexProperty and (edge) Property are implicit types. I don't know > > if this is ok. Could they ever be used outside of their parents where > > they would need to be typed? > > I agree with the VertexProperty remark. That's one last question I wanted > to solve, if we go for typing Vertex and edges, do we include others? The > full list I see then is : vertex/edge/vertexproperty/property/graph. > > However I am not sure how useful it is to have more than Vertex and Edge. > As, when deserializing a Vertex for example, there's no question as to what > is in the "properties" field of the Vertex, there are necessarily only > VertexProperties. However looking at the API, it seems like it is supported > to write only a VertexProperty if one wants to (see > GraphWriter.writeVertexProperty()), so in that case, to me it makes sense > to add the types for the elements of the list I described above. @stephen > any thoughts about that ?
I guess we should type them to be consistent and because they might return independently of a Vertex/Edge as Robert suggests. > - Edges: > > - is in/outVLabel new? Couldn't find it in the API or any examples of > this. > > - why not make inV/outV have proper vertices with labels (to satisfy > > the case previous case) instead of just IDs? This would also be more > > consistent with the API. > > I haven't touched that part, it was in the format before. I believe this > is a question for Stephen. Returning a "proper" vertex for inV/outV would be nice but it's potentially forcing the underlying graph database to pull a lot of data when the user only requested an edge to be returned. I don't think we should go that far. On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com < gallardo.kev...@gmail.com> wrote: > > > On 2016-07-19 18:02 (+0100), Robert Dale <robd...@gmail.com> wrote: > > - It seems redundant to nest a vertex or edge inside a type-value > > object and is inconsistent with a VertexProperty. > > - VertexProperty and (edge) Property are implicit types. I don't know > > if this is ok. Could they ever be used outside of their parents where > > they would need to be typed? > > I agree with the VertexProperty remark. That's one last question I wanted > to solve, if we go for typing Vertex and edges, do we include others? The > full list I see then is : vertex/edge/vertexproperty/property/graph. > > However I am not sure how useful it is to have more than Vertex and Edge. > As, when deserializing a Vertex for example, there's no question as to what > is in the "properties" field of the Vertex, there are necessarily only > VertexProperties. However looking at the API, it seems like it is supported > to write only a VertexProperty if one wants to (see > GraphWriter.writeVertexProperty()), so in that case, to me it makes sense > to add the types for the elements of the list I described above. @stephen > any thoughts about that ? > > > - Edges: > > - is in/outVLabel new? Couldn't find it in the API or any examples of > this. > > - why not make inV/outV have proper vertices with labels (to satisfy > > the case previous case) instead of just IDs? This would also be more > > consistent with the API. > > I haven't touched that part, it was in the format before. I believe this > is a question for Stephen. > > > > > Otherwise looks good! > > Thanks for the feedback. > > > > On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com > > <gallardo.kev...@gmail.com> wrote: > > > > > > > > > On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"< > gallardo.kev...@gmail.com> wrote: > > >> > > >> > > >> On 2016-07-09 16:48 (+0100), Stephen Mallette <spmalle...@gmail.com> > wrote: > > >> > With all the work on GLVs and the recent work on GraphSON 2.0, I > think it's > > >> > important that we have a solid, efficient, programming language > neutral, > > >> > lossless serialization format. Right now that format is GraphSON > and it > > >> > works for that purpose (ever more so with 2.0). Given some > discussion on > > >> > the GraphSON 2.0 PR driven a bit by Robert Dale: > > >> > > > >> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389 > > >> > > > >> > I wonder if we shouldn't consider another IO format that has Gremlin > > >> > Server/GLVs in mind. At this point I'm not suggesting anything > specific - > > >> > I'm just hanging the idea out for further discussion and brain > storming. > > >> > Thoughts? > > >> > > > >> > > >> Hey, so I'm trying to gather all infos we have here in order to > prepare to move forward with the implem of GraphSON 2.0, here's what I come > up with : > > >> > > >> Things we have : > > >> - Type format. > > >> - The structure in Jackson to implement our own type format. > > >> - All non native Graph types are typed (except the domain specific > types). > > >> > > >> New things we need : > > >> - Types for domain specific objects. > > >> - Types for all numeric values. > > >> - Don't serialize empty fields (outV and stuff). > > >> > > >> Things we consider changing : > > >> - Type IDs convention. Before : Java simple class names. Now : starts > with a "domain" like "gremlin" followed by the "type name", which is a > lowercased type name (like "uuid", or "float", or "vertex"). Example : > "gremlin:uuid". > > >> - Type format ? > > >> > > >> Am I missing something ? > > >> > > > Hey, > > > > > > So I've made a few changes in the code from the original GraphSON 2.0, > with the objectives described above, the code is still messy but I just > thought I'd share some samples to start getting into the work and gather > some feedback. > > > > > > In the example I've created a TinkerGraph with 2 vertices connected by > an edge. The graph is serialized as a TinkerGraph. > > > The samples are there : > https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60 > > > > > > Any feedback appreciated. > > > > > > > > -- > > Robert Dale > > >
