[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed Arrow Graph representations

Hi Wes,
I'm sure we're going to run into this with libgdf/pygdf as well.  Is there a systematic way we could do a transfer of IP?

On 5/20/18, 7:05 PM, "Wes McKinney" <wesmckinn@xxxxxxxxx> wrote:

    hi Paul,
    This is a great discussion to get started. I will review the patch in
    some more detail and send feedback
    > I've pushed Joe's initial GraphSchema.fbs to this branch on my Arrow fork
    I'm concerned the way this patch is set up right now is a little bit
    problematic from an IP lineage standpoint (since this is his/Nvidia's
    code and not yours). Would it be possible for Joe to create a pull
    request directly for this instead? We can create a branch somewhere
    where we can collaborate, too, if that helps.
    On Sat, May 19, 2018 at 11:35 PM, Paul Taylor <ptaylor@xxxxxxxxxx> wrote:
    > At GTC San Jose last month, NVidia's Joe Eaton (cc'd) presented on the
    > nvGraph <https://developer.nvidia.com/nvgraph> team's goals for
    > accelerating in-memory graph processing and analytics. A major component of
    > that is advancing and standardizing a common, efficient representation for
    > graphs that can support a broad ranges of use-cases, from small to large.
    > To that end, I'd like to kick off the discussion about native graph
    > representations in Arrow.
    > Joe's team has prepared a preliminary FlatBuffers schema for efficient
    > columnar representations of the four most common graph formats. It includes
    > embedded edge and vertex property tables, and is designed to be compatible
    > with the existing Arrow column types. My initial thoughts are that we could
    > add an optional 5th Graph Message type, similar to how Tensor Messages are
    > presently implemented.
    > I've pushed Joe's initial GraphSchema.fbs to this branch on my Arrow fork
    > <https://github.com/trxcllnt/arrow/blob/78f6b6c6a5b9e4e7bf96f5bbc4dfed7528b1cca7/format/GraphSchema_Triples_Quads.fbs>.
    > From what I understand, the tables have been expanded into separate
    > definitions for the sake of comprehension, and the final forms will be
    > collapsed into each distinct Graph type, parameterized by sizes defined at
    > the top.
    > I also understand the nvGraph team supports these layouts natively,
    > enabling the community to take advantage of high-performance GPU kernels
    > very early on, and possibly align with libraries like Hornet
    > <https://github.com/hornet-gt/hornetsnest> (previously cuStinger).
    > Cheers,
    > Paul

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.