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
<squar...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to