Re: [help-GIFT] Specifying feature groups in gift-config.mrml

[Wolfgang Müller]

> Hi again,

Rebonjour :-) 

> I think I have worked out why we seemed to be talking past each other on
> this topic last month. It is about the perceived role of the gift-config
> file. Please correct me if I am off the mark, but...

Oh, no, this was not the problem. My initial problem was that your added this 
discussion on top of a discussion what MRML itself should be. I think your 
problem is a problem regarding the usability of the GIFT server. So this took 
me some time to switch in order to get your drift. Then I was waiting for a 
handshake if we put the offline part of the discussion online again.

> I think that it is currently seen as a mechanism which the server uses
> to store information it needs to operate and answer MRML queries. Even
> though the feature extraction and collection adding are done by programs
> and scripts that are not part of the gift executable, they are seen
> conceptually as "part of the server".

OK.

> I am suggesting a departure from that view. I like the idea that the
> gift-config file can be used for communication between other programs
> and the gift (as it is now de facto). It is a place where they can
> register information about collections they have created etc. The goal
> would be to have the gift server executable know about a range of
> generic index and feature types, and the registering program could then
> register feature group names and ids, and associate them with such
> types. No recompilation necessary to get client-controlled feature
> blocking/weighting working.

Let's sort this out a bit. There are two reason why the server needs 
recompilation is that the blockColorFeatures() things don't take the feature 
type as parameter. We would need a function blockFeatures(featureType) 
instead. The other reason is that we decide if something is a histogram 
feature or not by the feature type. This could also become more generic by 
just a few lines. If you've got a student who wants to code that I would be 
ready to point him (or her) there more clearly on this list.

The other thing you suggested is more tricky, and I think the thing to do 
would be to have the plugins generate some of the gift-config.mrml by 
themselves. How to do this best would be another thing to discuss.

> I appreciate that this is possible now in principle, by having multiple
> directories with multiple inverted files, and constructing query trees,
> so in a sense I guess I am just being lazy about constructing such
> trees. I find it conceptually nicer to have features for a single
> collection in a single directory.

Ough, after this time I am lacking the picture there.

Cheers,
Wolfgang

-- 
Dr. Wolfgang Müller
LS AI 1
Universität Bayreuth