[Networkit] Request for comments: How to read attributes in graph files?

Christian Staudt christian.staudt at kit.edu
Wed Sep 2 13:13:50 CEST 2015

On 02 Sep 2015, at 12:12, Maximilian Vogel <maximilian.vogel at student.kit.edu> wrote:

>> One basic idea would be to add a method like this to the readers that support attributes:
>> 	GraphReader.getAttribute(key) : list[string]
>> Any other ideas?
> What would your getAttribute(key)-function actually do? Return a container of attributes created during the read(path)-function or read the file again for the attributes of the queried key?

Return a container of attributes created during the read(path)-function, to read the file only once.

> A convenience function that lists the available keys might be useful as one usually doesn't know the available attributes (except one looked into the file).


> A distinction between node and edge attribute might be necessary. Also, the data structure should be different:
> - map/dictionary: arbitrary node id -> graph internal node id
> - list/vector: graph internal node id -> attribute value/arbitrary node id
> If a graph has a lot of deleted nodes, it's probably more efficient to use a map/dictionary for the second type aswell.#

Attributes should be easily retrievable by NetworKit’s internal node (or edge) ids and compact, that’s why I wrote list/vector.

> Regarding the GraphReader class, various approaches should be considered:
> - One could argue, that you always want to have a graph, but not necessarily its attributes, so the read()-function reads the file and returns the graph object. For attributes, the getAttribute()-function can be used. [corresponds to your suggestion and also the current state]

That’s a viable approach.

> - The GraphReader class gets a method process() which reads the file and creates all the objects like the Graph, attributes and mappings. Then, various getter-functions can be used to retrieve the desired objects.

That would be even cleaner and more consistent with our current design pattern for classes, but leads to much refactoring.

> Also, if you just return a list or dictionary containing your attributes, you have no meta information which attribute it is. You know it because you stated an explicit key in the getAttribute(key)-function, but you can't "ask" the attribute object which key it has. Maybe a custom attribute class that wraps the underlying container and provides convenience functions like getKey(), setKey(), isNodeAttribute(), isEdgeAttribute() or similar would be helpful.

You know which attribute it is because you asked for it in the first place. You then store the key together with the attribute list. I’m not a fan of custom collection classes in general, standard library data structures are just fine for this purpose.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20150902/b54bf52b/attachment.sig>

More information about the NetworKit mailing list