Re: [help-GIFT] Ping!

[risc]

On Wed, May 03, 2006 at 05:05:39PM +0100, David Squire wrote:
> Wolfgang Müller wrote:
> >Thanks for your quick answer.
> >
> >  
> >>I take you point, but this is something that I am quite likely to have
> >>time to look at - on the scale of "some time this year". If we are to go
> >>down that path, we need to kick around some ideas on how we would like
> >>such a system to work.
> >>    
> >
> >I have thought about this. After my experience with c libraries as 
> >plugins, I am a bit weary. Some recent problems we had are still related 
> >to plugins. People have to versions of a lib floating around, and libtool 
> >picks the wrong one. 
> >
> >I would suggest that the feature extractors are programs that read from 
> >stdin a list of urls and output a list of file locations via stdout. After 
> >indexing, these locations are fed to something that aggregates the 
> >indexing data and adjusts the config.

i would disagree. ;)

i think the URL centricness of gift has been a pain, to me. i've had to hack up
my Client.php to re-write some URLs.
then again, i may be misconfigured.

however, i like the present method of the feature extractor.
if i were to make a change, i'd work on a batch mode.

unix utilities are commonly written to accept input on stdin, and output on 
stdout. 
if i were to make a modification to the feature extractor, i'd make it perform 
as that,
then you dont need a "plugable system". the only change i ever made to switch
between my version and yours was in gift-add-collection.pl, to change the 
executable name. 

to me, it seems ideal to ship multiple 'feature extractors', and pass the name
of the feature extractor to use to gift-add-collection.pl

the "isolated nature" of the feature extractor code is part of what let me 
make these improvements. i'm no c++ programmer. ;)

> >
> >This would be slightly hackish, but fast and flexible and it would be 
> >low-impact on the code.

mine would be more hackish, but "fits better" with unix philosophy.

> >  
> Yes. I agree that this seems a sensible approach. I would also be keen 
> to see some MRML extensions to support some basic descriptions of the 
> feature groups that go with a collection, most importantly the way 
> similarity should be calculated for the feature group (e.g. histogram 
> intersection, Euclidean distance, tf.idf, etc.)
> 
> It would be good to think about this over the next few weeks/months. I 
> think an extension in this direction would really improve the usability 
> of the framework (cf. the "symbols discussion earlier today). There 
> could be a default set of provided similarity calculators (based on what 
> is already there), and perhaps a provision for users to provide others 
> (possibly plugins again, but perhaps also by providing subclasses and 
> editing a nice clear source file that delegates these things).
> 

i'm excited to hear about this. ;)

Julia Longtin <address@hidden>