help-gift
[Top][All Lists]
Advanced

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

Re: [help-GIFT] Understanding MRML: Purpose of the "allows-children" ele


From: Ralf Juengling
Subject: Re: [help-GIFT] Understanding MRML: Purpose of the "allows-children" element?
Date: 01 Jul 2002 11:38:21 +0200

Hi,

thanks for your answer, but I still don't fully understand.

> BTW are you rather going to adapt your server, or would you be rather
> going for the GIFT/YourSystem plugin solution?

We are going to incorporate MRML into our system and will not use GIFT
at first. I'm sure you agree, that MRML shouldn't be tied to GIFT but 
is meant to support any kind of image search engine. On the other hand,
when reading your TR on MRML, I'm missing an introduction of the "basic 
notions", the protocol "talks about". When you wrote the spec, you had
-- having the GIFT system in mind -- perfectly clear ideas of what a
"collection", an "algorithm", a "query-paradigm" and a "query-step" is.
With some of these notions, I'm still not sure that I got you right.
Let's go on talking about "algorithm":

> OK. In MRML, you can specify trees of algorithms. This means, you can combine 
> your algorithm during runtime from blocks. This is done in GIFT/Viper in 
> order to do the separate normalization thing (four feature groups, that are 
> combined with equal weights or chosen weights as it is done in Monash). In 

At first I thought, "algorithms" are doing the query processing, 
(that's why they have to specify the supported query-paradigm).
But you denote something more low-level with "algorithm". 
I copied this from a GIFT's answer to a "get-algorithms"-message:

<algorithm  algorithm-id="a-cidf" algorithm-name="Classical IDF"
algorithm-type="a-cidf" collection-id="c-18-3-3-7-11-101-5-340-0"
cui-base-type="inverted_file" cui-block-color-blocks="no"
cui-block-color-histogram="no" cui-block-texture-blocks="no"
cui-block-texture-histogram="no" cui-pr-percentage-of-features="70"
cui-weighting-function="ClassicalIDF" >
<query-paradigm-list  >
<query-paradigm  />
</query-paradigm-list>

...
</algorithm>

As the value "Classical IDF" of algorithm-name suggests, this 
algorithm element represents a feature weighting algorithm. There
are attributes "cui-block-color-histogram" and so on; these are
parameters to this feature-weighting algorithm, I think.
Do "algorithm" elements always represent feature-weighing 
algorithms?

Later on in the message it reads:

<algorithm  algorithm-id="adefault" algorithm-name="Separate 
Normalisation" algorithm-type="adefault" 
collection-id="c-18-3-3-7-11-101-5-340-0" cui-base-type="multiple" 
cui-block-color-blocks="no" cui-block-color-histogram="no" 
cui-block-texture-blocks="no" cui-block-texture-histogram="no" 
cui-pr-percentage-of-features="70" 
cui-weighting-function="ClassicalIDF">

<algorithm  algorithm-id="sub1" algorithm-name="sub1"
algorithm-type="sub1" cui-base-type="inverted_file" 
cui-block-color-blocks="yes" cui-block-texture-blocks="yes" 
cui-block-texture-histogram="yes" cui-pr-percentage-of-features="100"/>

<algorithm  algorithm-id="sub2" algorithm-name="sub2" 
algorithm-type="sub2" cui-base-type="inverted_file" 
cui-block-color-histogram="yes" cui-block-texture-blocks="yes" 
cui-block-texture-histogram="yes" />

<algorithm  algorithm-id="sub3" algorithm-name="sub3" 
algorithm-type="sub3" cui-base-type="inverted_file" 
cui-block-color-blocks="yes" cui-block-color-histogram="yes" 
cui-block-texture-blocks="yes" cui-pr-percentage-of-features="100" />

<algorithm  algorithm-id="sub4" algorithm-name="sub4" 
algorithm-type="sub4" cui-base-type="inverted_file" 
cui-block-color-blocks="yes" cui-block-color-histogram="yes" 
cui-block-texture-histogram="yes" />

<query-paradigm-list  >
<query-paradigm  />
</query-paradigm-list>
...
</algorithm>

Maybe this is a good example to explain some ideas about an
algorithm-tree:

What kind of algorithms do the algorithms "sub1"... "sub4" stand for?
What property is indicated by the tag "algorithm-type"?
What property is indicated by the tag "cui-base-type"?


> fact, on the demo page, each query is forwarded by a dispatcher (of class 
> CQMultiple, if I'm not wrong. To be found in libMRML/cc/CQMultiple.cc, the 
> header being in libMRML/include/CQMultiple.h) to four CQInvertedFile (in 
> libGIFTQuInvertedFile/....) query engines. These are instances of the same 
> class, but differing runtime configuration.
> 

Please try to resist the temptation to explain the protocol in terms
of the GIFT system. (Of course, it's always a good idea to provide an
example, though ;)


> So. The allows-children allows you to specify, what algorithm can have what 
> other algorithm as child in the algorithm tree. The same matching is applied 
> as when matching query-paradigm tags among collections and algorithms. As 
> this tag came later, the default is: all children allowed. Yes, there should 
> be something that forbids children, then, so the hottest candidate for that 
> is to officially change the default, as (to my knowledge) no client or server 
> is using this tag, currently.

My current idea is that of a "meta-query": 
Several algorithms are prompted to build a ranking (with respect to
the relevance data of query-step element) by some root algorithm. Then
the root algorithm combines these rankings into one ranking...


Thanks for your patience, ;)
Ralf


-- 
-------------------------------------------------------------------------
Ralf Jüngling
Institut für Informatik - Lehrstuhl f. Mustererkennung &
Bildverarbeitung
Georges-Köhler-Allee
Gebäude 52                                       Tel:
+49-(0)761-203-8215
79110 Freiburg                                   Fax:
+49-(0)761-203-8262
-------------------------------------------------------------------------




reply via email to

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