[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-GIFT] Ping!
From: |
risc |
Subject: |
Re: [help-GIFT] Ping! |
Date: |
Wed, 3 May 2006 12:06:36 -0500 |
User-agent: |
Mutt/1.4.1i |
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>
- [help-GIFT] Ping!, risc, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, risc, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!,
risc <=
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/04
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/03