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

[Ralf Juengling]

> Would you agree writing some FAQ after this discussion? It could be cool to 

Yes I do. 

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

If I remember right, the query-paradigm-list might be empty and an
empty query-paradigm-list matches any query-paradigm-list. I think
this is dangerous, since -- as I expressed in another mail -- 
there are more query-paradigms to incorporate and the legal values
of the type-attribute should be specified by the protocol...

[...]

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

I understand, that the "matching-rule" is very flexible, but I don't
agree that's a good idea to misuse the query-paradigm tag for this
purpose.

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

[from above]:
> algorithm: 
> configuration data for query processing unit. 

But here you speak of a "query processing unit" as a building
block of the system. And the "algorithm" denoted in the 
protocol must serve this 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

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

So: a feature-weighting algorithm serves the query processing unit
by doing the feature weighting, thus it is "more low-level" then
the query processing unit.
(Don't get me wrong if I sound finical, I'm just on the way completing
the puzzle.)

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

Can you give some examples what you have in mind here (i.e. what 
algorithm-type might be)?


Thanks,
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
-------------------------------------------------------------------------