[Top][All Lists]

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

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

From: David Squire
Subject: [help-GIFT] Specifying feature groups in gift-config.mrml (was Re: Looking for an MRML DTD)
Date: Tue, 10 Aug 2004 19:06:33 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Wolfgang Müller wrote:

On Thursday 05 August 2004 17:50, Phil McConchie wrote:

Bayreuth had lots of problems with their mail server, so your reply has not arrived here, yet, so I do some cut and paste and answer that.

Oh OK, I have read in the specs about one of the primary objectives being
extensibility but thought that there might be an XML DTD floating about that
nailed down the exact element and attribute names for those parts of MRML
that appear from the specs to be concrete.

I think the most concrete DTD in use is that within the GIFT distro. However, it blithely ignores things like get-configuration and get-server-properties, as they are "stubs" added to the DTD for the case where someone wants to do something more complicated.


While we're on this topic, I have a student who is looking for the same thing :)

I have been thinking about things that should be in MRML. One of the weaknesses is that there is no way for specifying the feature groups (and their types) that go with each collection. I am thinking that such information should be associated with each collection, and algorithms specified for that collection should make use of the names defined for that collection. This would be a start of some name-spacing for features. I am thinking of something along the lines of:

   <collection collection-id="....>
<feature-group name="cui-color-histogram" type="histogram" id="0"/>
         <feature-group name="cui-color-blocks" type="frequency" id="1"/>
<feature-group name="cui-texture-histogram" type="histogram" id="2"/> <feature-group name="cui-texture-blocks" type="frequencies" id="3"/>
         <feature-group name="monash-text" type="frequency" id="4"/>
         <feature-group name="monash-eigenface" type="vector" id="5"/>

Clearly we would need to do some brainstorming on what "types" should be supported in the core GIFT, and what similarity functions for each type (e.g. histogram intersection for the "histogram" type, Euclidean distance for the "vector" type, etc.).

Algorithms that wanted to block or weight feature groups could then do something like

<feature-group name="cui-color-histogram" block="no" weight="0.125"/>
         <feature-group name="cui-color-blocks" type="no" weight="0.125"/>
<feature-group name="cui-texture-histogram" type="no" weight="0.125"/> <feature-group name="cui-texture-blocks" type="no" weight="0.125"/>
         <feature-group name="monash-text" type="no" weight="0.5"/>
         <feature-group name="monash-eigenface" type="yes" weight="5"/>
A bit drastic, I know, but it would greatly add to the ease of extensibility for use by other groups.



PS. The "id" thing is very much a hack, but I can see how it would be useful - of course the gift-indexing-data directory for a collection should really contain some feature-group-definitions file that resolves this mapping.

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

reply via email to

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