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" <[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]
