commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [graph] graph importers
Date Sun, 25 Mar 2012 20:48:05 GMT
Hola Claud.io,

I asked you to show some code because I didn't understand how you
would use reintroducing the Vertex/Edge in the exporter - maybe if you
could develop few interfaces in the branch would help a lot
understanding and discussing improvements...

WDYT?
best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Sun, Mar 25, 2012 at 6:38 PM, Claudio Squarcella
<squarcel@dia.uniroma3.it> wrote:
> Hi,
>
>
> On 25/03/2012 17:33, Simone Tripodi wrote:
>>
>> Hi Claud.io
>>
>> 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?
>
> Cheers,
> Claudio
>
>
>>
>> Looking forward to read about it!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Mar 25, 2012 at 3:20 PM, Claudio Squarcella
>> <squarcel@dia.uniroma3.it>  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
>>>
>>>
>>> ...wow that was long. What do you [graph]ers think? :)
>>>
>>> Ciao,
>>> Claudio
>>>
>>> --
>>> Claudio Squarcella
>>> PhD student at Roma Tre University
>>> http://www.dia.uniroma3.it/~squarcel
>>> http://twitter.com/hyperboreans
>>> http://claudio.squarcella.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> http://www.dia.uniroma3.it/~squarcel
> http://twitter.com/hyperboreans
> http://claudio.squarcella.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message