[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?
Tue, 2 Jul 2002 08:37:18 +0200
On Monday 01 July 2002 11:38, Ralf Juengling wrote:
> 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.
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
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.
name designates "one step in the query process"
container for the queries itself, like QBE etc.
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":
> 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.
> 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
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
> 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.
> 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