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

[David Squire]

David Squire wrote:

[snip]

> I agree that it provides this, but as I understand it, it requires the 
> server *code* already to know about things like cui-block-color-blocks 
> etc. I am thinking about a solution that would enable this kind of 
> thing with no need to write code or recompile the server. I want to be 
> able to just drop fts files (and a nice XML feature description file) 
> into the gift-indexing-data directories, edit gift-config.mrml and 
> have things work "out of the box".
>
> The idea is that the server provides some standard similarity 
> calculation tools for known generic feature group types (e.g. 
> histogram, frequency, vectorspace). Using GIFT with any such feature 
> group should not require recompilation.
>
> Perhaps I am wrong, but I don't think that this is possible at present.
Hi again,

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...

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".

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.

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.

Cheers,

David

--
Dr. David McG. Squire, Postgraduate Research Coordinator (Caulfield),
Computer Science and Software Engineering, Monash University, Australia
CRICOS Provider No. 00008C       http://www.csse.monash.edu.au/~davids/