[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-GIFT] Understanding MRML: Purpose of the"allows-children" elem
Re: [help-GIFT] Understanding MRML: Purpose of the"allows-children" element?
02 Jul 2002 14:42:01 +0200
> 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.
> 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
> As the client only checks if things match, it does not have to worry about
> 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,
> > (that's why they have to specify the supported query-paradigm).
> > But you denote something more low-level with "algorithm".
> Don't think so.
> 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
> > Do "algorithm" elements always represent feature-weighing
> > algorithms?
> No. Algorithms can be any kind of query processing unit. An algorithm
> 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
> > 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)?
Institut für Informatik - Lehrstuhl f. Mustererkennung &
Gebäude 52 Tel:
79110 Freiburg Fax: