commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claudio Squarcella <>
Subject Re: [graph] graph importers
Date Sun, 25 Mar 2012 16:38:56 GMT

On 25/03/2012 17:33, Simone Tripodi wrote:
> Hi
> I honestly felt I little lost - code would speak better than thousands
> of words, what about branching once again and make a concrete
> proposal? ;)

Sure I'll open a branch for that. But first I would like to validate my 
thoughts (at least partially), that is why I'm writing poems for now :)

An example: I'm very far from understanding how to exactly model the 
return type for importers. It should give access to both the graph and 
its properties, with particular emphasis on the ones that are relevant 
in [graph] like edge weights, vertex labels, etc. Any take on that?


> Looking forward to read about it!
> -Simo
> On Sun, Mar 25, 2012 at 3:20 PM, Claudio Squarcella
> <>  wrote:
>> Hi all,
>> the implementation of importers for [graph] requires a bit of attention, in
>> particular with the new model where
>>   * there are no explicit markers for Vertex and Edge,
>>   * all properties of Vertices and Edges are now specified with generic
>>    Mappers.
>> Writing and extending exporters is fine: we first specify the graph, then
>> its properties one after the other in a "fluent chain". The exporter simply
>> forgets about the types of Vertex/Edge and serializes the whole input.
>> Importing back a graph from an input source, however, is not as simple
>> because:
>>   * standard file formats give us no indication about Vertex/Edge types;
>>   * serialized graphs come with a number of properties, some of which we
>>    know and sometimes need for graph processing (e.g. labels and
>>    weights), while some others are not (yet?) recognized in the code;
>>   * the return type of any importer should account for both the graph
>>    itself and all the properties.
>> As a first step, these are my suggestions for the design:
>>   * we need at least default, empty implementations for Vertex and Edge;
>>    together with that, we could do some black magic to allow the user
>>    to specify what types should be used to map imported Vertices/Edges
>>    to actual classes.
>>   * we need a structure to host both the imported graph and properties.
>>    And it should be easy for the user to query such a structure for
>>    specific graph properties, i.e. we need to isolate properties that
>>    we recognize and use in our algorithms (e.g. weights). Other
>>    properties could be either ignored or imported with a reference to
>>    their name in the input format.
>> One way could be to explicitly ask the user to list all the properties that
>> he expects from the input graph, raising exceptions if they are not found.
>> Something like:
>>   * importGraph().asGraphML( "graph1.gml"
>>    ).withEdgeWeights().withVertexLabels(); // only two properties
>>    loaded and explicitly identified
>>   * importGraph().asGraphML( "graph2.gml" ).withAllProperties(); // all
>>    properties are loaded, none is explicitly recognized
>> that was long. What do you [graph]ers think? :)
>> Ciao,
>> Claudio
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Claudio Squarcella
PhD student at Roma Tre University

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message