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

[Wolfgang Müller]

On Monday 01 July 2002 11:38, Ralf Juengling wrote:
> 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.

Yes. But you will allow me some egoism: I was trying to get someone outside 
the "Geneva connection" contribute a serious plugin ;-)

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

Would you agree writing some FAQ after this discussion? It could be cool to 
have someone do that who has more the outside view.

I will try to give a short explanation before answering your question in 
detail. Gotta look in my thesis if I did not describe it there.

algorithm: 
configuration data for query processing unit. 
operates on a collection. 
can be combination of other algorithms. 
minimal algorithm should contain algorithm-id and algorithm-type, and 
algorithm-name (displayed by client).
can contain query-paradigm-list
can contain allows-children

an algorithm can have only children whose query-paradigm-list matches 
allows-children

collection: 
minimal: collection-id collection-name
can contain query-paradigm-list tag.
This should be all a client worries about

can be only used with algorithm whose query-paradigm-list matches.

query-step:
name designates "one step in the query process"
container for the queries itself, like QBE etc.

query-paradigm-list:
intended as query paradigm descriptor.
 after specification it was realized that this is flexible enough for 
describing quite a number of things.

How it works?
Strict match or non-match.
Two qpl (qpl1, qpl2) match if at least one element of qpl1 matches at least 
one element of pql2. 
Two qp  (the french might forgive me this abbreviation ;-) ) (qp1, qp2) match 
if their attributes match in the following fashion: intersect the sets of 
attribute keys of qp1 and qp2, to obtain the set kset. If there exsists a k 
from kset, for which value(qp1,k)!=value(qp2,k), then qp1,qp2 DONT MATCH. 
otherwise they do.

===> You can use this mechanism for describing the query paradigm (for which 
it was intended), however also for things like describing (within your 
system) the indexing structure etc. . It's a general description for "what 
fits with what".  

As the client only checks if things match, it does not have to worry about the 
details, except for negotiation which controls to give to the user. If I 
remember right this was just the content of the discussion with Pruet, so I 
will try to find that mail and post it here.

> Let's go on talking about "algorithm":

Good idea.

>
> At first I thought, "algorithms" are doing the query processing,

Yessir.

> (that's why they have to specify the supported query-paradigm).
> But you denote something more low-level with "algorithm".

Don't think so.


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

Yes, that's right.

> Do "algorithm" elements always represent feature-weighing
> algorithms?

No. Algorithms can be any kind of query processing unit. An algorithm operates 
on a collection.

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

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

OK. All MRML asks is an algorithm to have an ID and a type. What sub1..sub4 
stand for can be seen in the cui-base-type: they are inverted_file feature 
weighting algorithms. This is a GIFT-specific tag. The other attribute 
(cui-block...) override the parameters set in the root of that algorithm 
tree.

> What property is indicated by the tag "algorithm-type"?

This is an identifyer chosen by you. The idea is (we never tested it, because 
we did not have the clients to do so) that you can specify several algorithms 
with different IDs and the same type, that can occur in the same tree. 
Parameters from the type could be overridden in each instance.

> What property is indicated by the tag "cui-base-type"?

This is a string which tells the factory what CQuery subclass to build.

> 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 ;)

This was what it is supposed to be.

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

Yes. That's it. MRML gives you the possibility to do that, and what you do 
with it is implementation dependent.

> Thanks for your patience, ;)

Oh, thanks for yours
Wolfgang