[help-GIFT] Specifying feature groups in gift-config.mrml (was Re: Looking for an MRML DTD)

[David Squire]

Wolfgang Müller wrote:

> On Thursday 05 August 2004 17:50, Phil McConchie wrote:
>  
>
> > Hi,
> >    
> Hi,
>
> 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.
>
>  
>
> > Wolfgang,
> > Re DTD:
> > 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.
>
>  
[snip]

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-list>
   <collection collection-id="....>
      <feature-group-list>
         <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"/>
      </feature-group-list>
...
   </collection>
...
</collection-list>

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

<algorithm>
      <feature-group-list>
         <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"/>
      </feature-group-list>
...
</algorithm>
        
A bit drastic, I know, but it would greatly add to the ease of 
extensibility for use by other groups.

Cheers,

David

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
http://www.csse.monash.edu.au/~davids/