Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Guidance on how to best implement labeled graphs in this library

Abierto
  • ¿Algo no está bien?
#82 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
julia
Área
data

Línea de trabajo

Empieza revisando la función loadgraphml existente y la estructura LabeledGraph propuesta. Compárala con GNNGraph de GNNGraphs.jl y con la discusión enlazada de Graphs.jl sobre los índices de aristas. El siguiente paso es resolver la API de etiquetado con los maintainers antes de preparar un pull request de un parser GXL.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

As part of a project I am working, I needed to read in graph files in the GXL graph format, including their label data.
As this format is not yet supported in this library, I would like to contribute my parser (which I wrote by modifying the existing loadgraphml function). The issue is that, as far as I can tell, there is no existing concept on how to implement graph labels in this library, or even in Graphs.jl.

There is an implementation of a labeled graph in GNNGraphs.jl (the GNNGraph), but I don't think this is the correct implementation to use in this library for two reasons:

  1. As I understand the code they rely on edge indices for the edge labels, which I believe is not officially supported by Graphs.jl (see this issue)
  2. It introduces an external dependency that is not really connected to this project

Instead, I have used the following struct to implement labeled graphs, the usage of Dicts inspired by the DataStore in GNNGraphs.jl:

GraphLabels = Dict{String, Any}
struct LabeledGraph
    g::AbstractGraph
    nlabels::Vector{GraphLabels}
    elabels::Matrix{Union{GraphLabels, Missing}}
end

I have used a matrix for the edgelabels to avoid having to index the edges. While it would clearly be more storage efficient to use a vector, I believe having to maintain an edge index list would be even more resource intensive than simply using a matrix. Additionally, one can easily extend this to use sparse matrices instead if the graph in question is sparse and large, and it neatly supports both directed and undirected graphs.

Since there is no precedent for this kind of structure, I propose that my parser for this library be split into two versions. One, which simply returns the underlying graph object, and thus conforms to the existing return structure. The other returns a LabeledGraph object as described above. In my opinion this is the best compromise between not parsing the extra label data at all and introducing a new graph object for everyone immediately.

The purpose of this issue is then to ask for opinions on this proposed implementation before I clean up my code for a pull request. Is this acceptable, or are there things I should do differently?

Lenguaje dominante
Julia
Estrellas
62
Forks
30
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de JuliaGraphs/GraphIO.jl

Todos los issues de JuliaGraphs/GraphIO.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.