You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@graphar.apache.org by Xiaokang <xi...@apache.org> on 2025/10/31 11:40:08 UTC
[VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Hello, Apache GraphAr(incubating) Community,
We recently held in-depth discussions with the LDBC LEX (LDBC Extended GQL
Schema) team. Based on these conversations, we propose making adjustments
to Graphar’s current Schema YAML format and would like to solicit your
feedback.
LEX, which is part of the GDC (Graph Data Council) Text2GraphQuery project
focused on property graphs, is a proposed strict superset of GQL graph
types and as a proposal to WG3 for possible future standardization. LEX
includes many of the same players as the WG3 international and INCITS U.S.
national standards bodies.
LEX has expressed strong interest in Graphar’s current approach of using
YAML to represent graph schemas, and we have already engaged in several
productive discussions on this topic.
Given the strong alignment between LEX’s goals for graph storage
standardization and Graphar’s own mission, we believe this presents a
valuable opportunity for collaboration. To better integrate with the LEX
ecosystem, we plan to adapt Graphar’s YAML format to conform as closely as
possible to LEX’s proposed syntax, this may require changes to our current
YAML structure.
We therefore seek your input: Should Graphar evolve its YAML schema based
on the LEX schema?
The VOTE will be open for at least 72 hours and until the necessary number
of votes are reached.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
To learn more about apache graphar, please see https://graphar.apache.org/
Re: [VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Posted by Zhe Wang <sp...@apache.org>.
+1, thank you to bring this!
On 2025/10/31 11:40:08 Xiaokang wrote:
> Hello, Apache GraphAr(incubating) Community,
>
> We recently held in-depth discussions with the LDBC LEX (LDBC Extended GQL
> Schema) team. Based on these conversations, we propose making adjustments
> to Graphar’s current Schema YAML format and would like to solicit your
> feedback.
>
> LEX, which is part of the GDC (Graph Data Council) Text2GraphQuery project
> focused on property graphs, is a proposed strict superset of GQL graph
> types and as a proposal to WG3 for possible future standardization. LEX
> includes many of the same players as the WG3 international and INCITS U.S.
> national standards bodies.
>
> LEX has expressed strong interest in Graphar’s current approach of using
> YAML to represent graph schemas, and we have already engaged in several
> productive discussions on this topic.
>
> Given the strong alignment between LEX’s goals for graph storage
> standardization and Graphar’s own mission, we believe this presents a
> valuable opportunity for collaboration. To better integrate with the LEX
> ecosystem, we plan to adapt Graphar’s YAML format to conform as closely as
> possible to LEX’s proposed syntax, this may require changes to our current
> YAML structure.
>
> We therefore seek your input: Should Graphar evolve its YAML schema based
> on the LEX schema?
>
> The VOTE will be open for at least 72 hours and until the necessary number
> of votes are reached.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> To learn more about apache graphar, please see https://graphar.apache.org/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@graphar.apache.org
For additional commands, e-mail: dev-help@graphar.apache.org
Re: 回复： [VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Posted by Sem <ss...@apache.org>.
+1 (binding)
From my side, I'm ready to work on updating the newly created Java Gar.
On Fri, 2025-10-31 at 23:12 +0800, yang_xk wrote:
> Dear Sem Sinchenko,
>
> I believe the URL you mentioned is part of the LEX draft. In the
> draft, LEX will be divided into two layers: logical and physical,
> with GraphAr mainly playing a role at the physical layer. LEX will
> introduce a more precise definition system, it will make GraphAr YAML
> schema more accurate and authoritative.
>
> To achieve this, we need to make some minor adjustments, For example,
> we can reconsider the design of valueType to improve
> compatibility across different storage systems such as Parquet and
> ORC. In addition, we may need to rename our type to label, which
> would help reduce the gap between graphAr and other graph systems.
>
>
>
>
>
>
>
> I’ve created a
> discussion https://github.com/apache/incubator-graphar/discussio
> ns/797 where we can design the implementation details to narrow the
> gap between GraphAr and LEX, and make our work better aligned.
>
>
> Best regards,
> xiaokang Yang
>
>
> ------------------ 原始邮件 ------------------
> 发件人:
>
> "dev"
> <ssinchenko@apache.org>;
> 发送时间: 2025年10月31日(星期五) 晚上9:12
> 收件人: "dev"<dev@graphar.apache.org>;
>
> 主题: Re: [VOTE] Proposal to Align Graphar Schema YAML with LDBC
> LEX
>
>
>
> Hello!
>
> Is this a right description of the LEX schema?
> https://github.com/alastai/grasch-lex/blob/main/snb-lex-2026.0.0-schema.yaml
>
> If so, I will read it in details. But I would like to postpone the
> voting and start from the discussion first.
>
> From the first look, it seems to me that it is not a big problem to
> at
> least generate LEX YAML/JSON from the existing GraphAr YAMLs. As well
> it looks feasible to generate GraphAr graph-info.yaml from LEX
> YAML/Json file.
>
> Overall because GraphAr is focused more on the storage aspects and
> LEX
> is focused more on the top-level property graph schema, I see nothing
> against changes and alignment. We just need to analyze it carefully
> and
> create a clear transition path with having back-compatibility as much
> as possible.
>
> Best regards,
> Sem Sinchenko, Apache GraphAr (incubating) PPMC
>
>
> On Fri, 2025-10-31 at 19:40 +0800, Xiaokang wrote:
> > Hello, Apache GraphAr(incubating) Community,
> >
> > We recently held in-depth discussions with the LDBC LEX (LDBC
> > Extended GQL
> > Schema) team. Based on these conversations, we propose making
> > adjustments
> > to Graphar’s current Schema YAML format and would like to
> solicit
> > your
> > feedback.
> >
> > LEX, which is part of the GDC (Graph Data Council)
> Text2GraphQuery
> > project
> > focused on property graphs, is a proposed strict superset of GQL
> > graph
> > types and as a proposal to WG3 for possible future
> standardization.
> > LEX
> > includes many of the same players as the WG3 international and
> INCITS
> > U.S.
> > national standards bodies.
> >
> > LEX has expressed strong interest in Graphar’s current
> approach of
> > using
> > YAML to represent graph schemas, and we have already engaged in
> > several
> > productive discussions on this topic.
> >
> > Given the strong alignment between LEX’s goals for graph storage
> > standardization and Graphar’s own mission, we believe this
> presents a
> > valuable opportunity for collaboration. To better integrate with
> the
> > LEX
> > ecosystem, we plan to adapt Graphar’s YAML format to conform as
> > closely as
> > possible to LEX’s proposed syntax, this may require changes to
> our
> > current
> > YAML structure.
> >
> > We therefore seek your input: Should Graphar evolve its YAML
> schema
> > based
> > on the LEX schema?
> >
> > The VOTE will be open for at least 72 hours and until the
> necessary
> > number
> > of votes are reached.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > To learn more about apache graphar, please see
> > https://graphar.apache.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@graphar.apache.org
> For additional commands, e-mail: dev-help@graphar.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@graphar.apache.org
For additional commands, e-mail: dev-help@graphar.apache.org
回复： [VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Posted by yang_xk <ya...@qq.com.INVALID>.
Dear Sem Sinchenko,
I believe the URL you mentioned is part of the LEX draft. In the draft, LEX will be divided into two layers: logical and physical, with GraphAr mainly playing a role at the physical layer. LEX will introduce a more precise definition system, it will make GraphAr YAML schema more accurate and authoritative.
To achieve this, we need to make some minor adjustments, For example, we can reconsider the design of valueType to improve compatibility across different storage systems such as Parquet and ORC. In addition, we may need to rename our type to label, which would help reduce the gap between graphAr and other graph systems.
I’ve created a discussion https://github.com/apache/incubator-graphar/discussions/797 where we can design the implementation details to narrow the gap between GraphAr and LEX, and make our work better aligned.
Best regards,
xiaokang Yang
------------------ 原始邮件 ------------------
发件人: "dev" <ssinchenko@apache.org>;
发送时间: 2025年10月31日(星期五) 晚上9:12
收件人: "dev"<dev@graphar.apache.org>;
主题: Re: [VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Hello!
Is this a right description of the LEX schema?
https://github.com/alastai/grasch-lex/blob/main/snb-lex-2026.0.0-schema.yaml
If so, I will read it in details. But I would like to postpone the
voting and start from the discussion first.
From the first look, it seems to me that it is not a big problem to at
least generate LEX YAML/JSON from the existing GraphAr YAMLs. As well
it looks feasible to generate GraphAr graph-info.yaml from LEX
YAML/Json file.
Overall because GraphAr is focused more on the storage aspects and LEX
is focused more on the top-level property graph schema, I see nothing
against changes and alignment. We just need to analyze it carefully and
create a clear transition path with having back-compatibility as much
as possible.
Best regards,
Sem Sinchenko, Apache GraphAr (incubating) PPMC
On Fri, 2025-10-31 at 19:40 +0800, Xiaokang wrote:
> Hello, Apache GraphAr(incubating) Community,
>
> We recently held in-depth discussions with the LDBC LEX (LDBC
> Extended GQL
> Schema) team. Based on these conversations, we propose making
> adjustments
> to Graphar’s current Schema YAML format and would like to solicit
> your
> feedback.
>
> LEX, which is part of the GDC (Graph Data Council) Text2GraphQuery
> project
> focused on property graphs, is a proposed strict superset of GQL
> graph
> types and as a proposal to WG3 for possible future standardization.
> LEX
> includes many of the same players as the WG3 international and INCITS
> U.S.
> national standards bodies.
>
> LEX has expressed strong interest in Graphar’s current approach of
> using
> YAML to represent graph schemas, and we have already engaged in
> several
> productive discussions on this topic.
>
> Given the strong alignment between LEX’s goals for graph storage
> standardization and Graphar’s own mission, we believe this presents a
> valuable opportunity for collaboration. To better integrate with the
> LEX
> ecosystem, we plan to adapt Graphar’s YAML format to conform as
> closely as
> possible to LEX’s proposed syntax, this may require changes to our
> current
> YAML structure.
>
> We therefore seek your input: Should Graphar evolve its YAML schema
> based
> on the LEX schema?
>
> The VOTE will be open for at least 72 hours and until the necessary
> number
> of votes are reached.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> To learn more about apache graphar, please see
> https://graphar.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@graphar.apache.org
For additional commands, e-mail: dev-help@graphar.apache.org
Re: [VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Posted by Sem <ss...@apache.org>.
Hello!
Is this a right description of the LEX schema?
https://github.com/alastai/grasch-lex/blob/main/snb-lex-2026.0.0-schema.yaml
If so, I will read it in details. But I would like to postpone the
voting and start from the discussion first.
From the first look, it seems to me that it is not a big problem to at
least generate LEX YAML/JSON from the existing GraphAr YAMLs. As well
it looks feasible to generate GraphAr graph-info.yaml from LEX
YAML/Json file.
Overall because GraphAr is focused more on the storage aspects and LEX
is focused more on the top-level property graph schema, I see nothing
against changes and alignment. We just need to analyze it carefully and
create a clear transition path with having back-compatibility as much
as possible.
Best regards,
Sem Sinchenko, Apache GraphAr (incubating) PPMC
On Fri, 2025-10-31 at 19:40 +0800, Xiaokang wrote:
> Hello, Apache GraphAr(incubating) Community,
>
> We recently held in-depth discussions with the LDBC LEX (LDBC
> Extended GQL
> Schema) team. Based on these conversations, we propose making
> adjustments
> to Graphar’s current Schema YAML format and would like to solicit
> your
> feedback.
>
> LEX, which is part of the GDC (Graph Data Council) Text2GraphQuery
> project
> focused on property graphs, is a proposed strict superset of GQL
> graph
> types and as a proposal to WG3 for possible future standardization.
> LEX
> includes many of the same players as the WG3 international and INCITS
> U.S.
> national standards bodies.
>
> LEX has expressed strong interest in Graphar’s current approach of
> using
> YAML to represent graph schemas, and we have already engaged in
> several
> productive discussions on this topic.
>
> Given the strong alignment between LEX’s goals for graph storage
> standardization and Graphar’s own mission, we believe this presents a
> valuable opportunity for collaboration. To better integrate with the
> LEX
> ecosystem, we plan to adapt Graphar’s YAML format to conform as
> closely as
> possible to LEX’s proposed syntax, this may require changes to our
> current
> YAML structure.
>
> We therefore seek your input: Should Graphar evolve its YAML schema
> based
> on the LEX schema?
>
> The VOTE will be open for at least 72 hours and until the necessary
> number
> of votes are reached.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> To learn more about apache graphar, please see
> https://graphar.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@graphar.apache.org
For additional commands, e-mail: dev-help@graphar.apache.org
回复：[VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Posted by "李雪(有理)" <yo...@alibaba-inc.com.INVALID>.
+1 binding
------------------------------------------------------------------
发件人：Xiaokang <xi...@apache.org>
发送时间：2025年10月31日(周五) 19:40
收件人：dev<de...@graphar.apache.org>
主 题：[VOTE] Proposal to Align Graphar Schema YAML with LDBC LEX
Hello, Apache GraphAr(incubating) Community,
We recently held in-depth discussions with the LDBC LEX (LDBC Extended GQL
Schema) team. Based on these conversations, we propose making adjustments
to Graphar’s current Schema YAML format and would like to solicit your
feedback.
LEX, which is part of the GDC (Graph Data Council) Text2GraphQuery project
focused on property graphs, is a proposed strict superset of GQL graph
types and as a proposal to WG3 for possible future standardization. LEX
includes many of the same players as the WG3 international and INCITS U.S.
national standards bodies.
LEX has expressed strong interest in Graphar’s current approach of using
YAML to represent graph schemas, and we have already engaged in several
productive discussions on this topic.
Given the strong alignment between LEX’s goals for graph storage
standardization and Graphar’s own mission, we believe this presents a
valuable opportunity for collaboration. To better integrate with the LEX
ecosystem, we plan to adapt Graphar’s YAML format to conform as closely as
possible to LEX’s proposed syntax, this may require changes to our current
YAML structure.
We therefore seek your input: Should Graphar evolve its YAML schema based
on the LEX schema?
The VOTE will be open for at least 72 hours and until the necessary number
of votes are reached.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
To learn more about apache graphar, please see https://graphar.apache.org/ <https://graphar.apache.org/ >