+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" > <[email protected]>; > 发送时间: 2025年10月31日(星期五) 晚上9:12 > 收件人: "dev"<[email protected]>; > > 主题: 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: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
