[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Squire
Subject: Re: [help-GIFT] Specifying feature groups in gift-config.mrml
Date: Tue, 28 Sep 2004 17:56:53 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

David Squire wrote:


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.



Dr. David McG. Squire, Postgraduate Research Coordinator (Caulfield),
Computer Science and Software Engineering, Monash University, Australia
CRICOS Provider No. 00008C

reply via email to

[Prev in Thread] Current Thread [Next in Thread]