Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Guidance on how to best implement labeled graphs in this library

Aperta
  • Qualcosa non va?
#82 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
julia
Ambito
data

Direzione di ricerca

Inizia esaminando la funzione loadgraphml esistente e la struttura LabeledGraph proposta. Confrontala con GNNGraph di GNNGraphs.jl e con la discussione collegata di Graphs.jl sugli indici degli archi. Il passaggio successivo consiste nel definire l'API di etichettatura con i maintainer prima di preparare una pull request per un parser GXL.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Julia
Stelle
62
Fork
30
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGraphs/GraphIO.jl

Tutte le issue di JuliaGraphs/GraphIO.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.