nice to hear that folks are still thinking about how GraphAR and TinkerPop
can work together.
> Can we understand that it means that one key corresponds to multiple
values, which needs to be represented by a list?
yes, a multi-property is a bit like storing the values in a list for a
single key, but a multi-property has some particularities to it:
gremlin> g.addV().property('name',['alice','bob'])
==>v[0]
gremlin> g.addV().property(list,'name','craig').property(list,'name','dave')
==>v[2]
gremlin> g.V(0l).properties()
==>vp[name->[alice, bob]]
gremlin> g.V(2l).properties()
==>vp[name->craig]
==>vp[name->dave]
in the above example, the 0 vertex stores a alice and bob as a list while
the 2 vertex stores craig and dave as a multi-property. you can see that
TinkerPop treats the latter as two separate properties which leads to other
differences:
gremlin> g.V().has('name','alice')
gremlin> g.V().has('name','dave')
==>v[2]
In the previous example, alice can't be found because "name" has a List
object to match on for vertex 0. But we can find dave because vertex 2 used
a multi-property which stores it as a string on a individual property.
This may all be Gremlin semantics that i'm describing and might not have
any impact on how you choose to implement the ability to model
"multi-properties" for GraphAR, but I thought i'd clarify their behavior a
bit in case that helped.
On Wed, Nov 20, 2024 at 3:01 AM Haoyu Liu <[email protected]> wrote:
> Hi,Stephen
> In order to better integrate with Gremlin, we have now implemented
> GraphAr's support for multi-label data, that is, a vertex can have multiple
> labels: https://github.com/apache/incubator-graphar/issues/614.
> The example is at
> https://github.com/apache/incubator-graphar/blob/main/docs/libraries/cpp/getting-started.md#processing-graph-data-with-labels
> .
> For 'multiproperties that are themselves of List type', Can we understand
> that it means that one key corresponds to multiple values, which needs to
> be represented by a list? We will raise an issue in the near future to make
> corresponding modifications.
> Regards,
> Haoyu Liu
>
>
> On 2024/05/27 02:19:55 "李雪(有理)" wrote:
> > Sorry for the late reply; TinkerPop would need to rewrite their
> input/output modules to adapt to GraphAr's APIs, similar to what we have
> done with GraphScope:
> https://github.com/v6d-io/v6d/commit/0eda2067e45fbb4ac46892398af0edc84fe1c27b
> <
> https://github.com/v6d-io/v6d/commit/0eda2067e45fbb4ac46892398af0edc84fe1c27b
> >.
> > In GraphAr, regarding handling multiple properties, employing a List
> is deemed practical. To differentiate these from properties that are
> inherently List-typed, it is advisable to either prepend a prefix to the
> property name or to leverage extra information (
> https://github.com/apache/incubator-graphar/blob/main/cpp/include/graphar/graph_info.h#L706
> <
> https://github.com/apache/incubator-graphar/blob/main/cpp/include/graphar/graph_info.h#L706
> >) contained within the GraphAr's meta-info YAML.
> > Alternatively, one could define each property separately and store
> them individually, taking advantage of the fact that null values are
> permissible.
> > ------------------------------------------------------------------
> > 发件人：Stephen Mallette <[email protected]>
> > 发送时间：2024年5月24日(星期五) 19:28
> > 收件人：dev<[email protected]>
> > 主 题：Re: Apache TinkerPop and GraphAr
> > Could you please share what you think are the main changes you would
> think
> > TinkerPop would have to make?
> > I also wonder a bit about multi/meta-properties and how they might
> fit into
> > the future of GraphAr. I don't find that a lack of support for either
> > multi/metaproperties is a huge blocker for adoption but i don't see
> those
> > things going away i the long term. I suppose multiproperties could be
> > coerced to List but I suppose that would preclude use of
> > multiproperties that are themselves of List type.
> > On Thu, May 23, 2024 at 9:28 PM 李雪(有理) <[email protected]
> >
> > wrote:
> > > Your understanding is accurate. Our integration strategy with
> Neo4j has
> > > been designed to be non-intrusive.
> > > For deeper integration, we have initiated efforts to adopt
> GraphAr as the
> > > primary format for importing and exporting in GraphScope, which
> has led to
> > > considerable performance improvements. You can find more details
> here:
> > >
> https://graphar.apache.org/docs/libraries/cpp/examples/graphscope <
> https://graphar.apache.org/docs/libraries/cpp/examples/graphscope > <
> > >
> https://graphar.apache.org/docs/libraries/cpp/examples/graphscope <
> https://graphar.apache.org/docs/libraries/cpp/examples/graphscope >
> >
> > > Furthermore, we have explored mechanisms to support certain
> pushdown
> > > operations tailored for graph querying scenarios, which reduces
> the
> > > necessity of loading the entire graph into memory. However,
> these features
> > > are still in the experimental phase and have not yet been
> incorporated into
> > > our main branch.
> > > As for integrating GraphAr with TinkerPop for OLAP use cases, my
> main
> > > concern is the potential impact on the execution engine. Such
> integration
> > > may require notable changes of the TinkerPop codebase, according
> to our
> > > experience with GraphScope.
> > > Despite these challenges, we are enthusiastic about engaging
> with the
> > > TinkerPop community. We would like to provide the necessary
> functionalities
> > > and any assistance regarding GraphAr support.
> > >
> ------------------------------------------------------------------
> > > 发件人：Stephen Mallette <[email protected]>
> > > 发送时间：2024年5月23日(星期四) 19:15
> > > 收件人：dev<[email protected]>
> > > 主 题：Re: Apache TinkerPop and GraphAr
> > > From what I understand from your documentation, it looks as
> though you
> > > provide ways to directly connect to Neo4j through a spark job. I
> assume
> > > there might be something similar you could do with Gremlin
> Server. That
> > > might be nice. In that way, users could convert any TinkerPop
> graph to
> > > GraphAr format.
> > > I suppose my main question though is whether or not it would be
> a good idea
> > > for TinkerPop to use GraphAr more directly as an input/output
> format for
> > > OLAP use cases? TinkerPop currently prefers use of Gryo, it's
> own format
> > > based on Kryo, but I feel like GraphAr could be a better choice
> going
> > > forward potentially. I'd be interested to hear what GraphAr
> experts think
> > > about this use case.
> > > On Tue, May 21, 2024 at 9:20 PM 李雪(有理)
> <[email protected]>
> > > wrote:
> > > > Hello, Stephen
> > > > Thank you for bringing up this interesting discussion
> point. As far as I
> > > > am aware, there have not been any formal discussions
> regarding a direct
> > > > collaboration between TinkerPop and GraphAr to this date.
> However, I
> > > > believe a collaborative effort in this area could lead to
> improvements in
> > > > how graph data is managed and processed.
> > > > Drawing from our experiences with integrating Neo4j and
> NebulaGraph, we
> > > > have gleaned insights that could prove invaluable in this
> context.
> > > > We are keenly interested in delving deeper into this
> conversation between
> > > > TinkerPop and GraphAr.
> > > >
> ------------------------------------------------------------------
> > > > 发件人：Stephen Mallette <[email protected]>
> > > > 发送时间：2024年5月21日(星期二) 21:02
> > > > 收件人：dev<[email protected]>
> > > > 主 题：Apache TinkerPop and GraphAr
> > > > Hello - I was just wondering if there have been any
> discussions about how
> > > > TinkerPop and GraphAr might work together a bit.
> TinkerPop's file system
> > > > formats have grown a bit dated to some degree and GraphAr
> seems like it
> > > > could be useful there as a replacement to internal formats,
> particularly
> > > > Gryo. Looking forward to hearing thoughts on this topic.
> Thanks!
> > > > Stephen
> > > >
> > >
> >
