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? ;)
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
