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


From: Wolfgang Müller
Subject: Re: [help-GIFT] Understanding MRML: Purpose of the"allows-children" element?
Date: Tue, 2 Jul 2002 16:11:33 +0200

> 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...
>
I think it depends on what you worry about. One of the principal worries in 
designing MRML was to keep the bar low for people who want to enter. This is 
a part of it.

Another worry was to try to propose solutions for which you would need a 
committee. MRML tries to propose solutions one step at a time: "I don't know 
what all query paradigms are, so I give you a flexible method to describe 
their relations with each other".

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

Reçu 5/5 (Reading you loud and clear). However, I do not quite agree. You 
might want to say, that the query-paradigm is an one-dimensional value. But 
you also might say, for example:

"What we are doing is QBE with the possibility for the user to do region 
queries to give more precise examples. We also allow Bayesian browsing when 
needed. Things are guaranteed to happen in interactive time."

I agree that query-paradigm at the time being is to narrow a name. However, I 
hesitate to rename this part, for fear of breaking compatibility.

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

Ugh. Here we are running into problems what we call low-level and high level.

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

No. That is not it. Lemme think.

OK. Let's speak in implementation cathegories. We will call CQuery the query 
processor. We will call CAccessor the structure that accesses some data 
representation of a collection.

We will call algorithm the contents of an algorithm tag, and we will call 
collection the contents of a collection tag.

Why the CQuery/CAccessor separation? We assume that the collection itself does 
not have any state. However, a query process might have a state (e.g. when 
browsing). Note: this does not have to be the case in your system. It COULD 
be the case in your system.

Now you want to configure your CQuery and your CAccessor. What your client 
will give you, is an algorithm tag containing among other things the 
collection-id of the collection that should be queried on (qpl etc.). Your 
server receives all this stuff, and uses it to configure its CQuery and 
CAccessor. And if this is not separated, but just CDoitAllInOneBigClass, then 
you use it to configure your CDoitAllInOneBigClass. Please note, that the 
query engine should be adequately preconfigured, if you come with an 
algorithm tag that contains only algorithm-id and algorithm-type.

For elaborating a bit more on the not-only-gift-theme: for this year's 
benchathlon, I wrote a perl wrapper, that simply passes anything useful on to 
some commandline script. Trees of meta-query processors? Nope, not needed. 
However, MRML suggests, that you can do it, and GIFT does it (at least to the 
level you see when going to the demo on viper).

type/id Globally it is the same as class/instance. The algorithm-id tells you 
about the instance of the algorithm, and the type is what an OO programmer 
would call class. All algorithms are either member of a type, or define a new 
one. Another algorithm (defined later in the same algorithm-list) then can 
define itself in terms of another, already defined algorithm. Type means here 
nothing more than that the attributes of the prototype will be copied into 
the new instance. Within the new instance we then have the possibility to 
overload the attributes with new values. This has never been tested, as the 
need was not big enough to write the corresponding client.

So an algorithm tag is (potentially) a tree of CQuery configuration data. If 
you match this tree with a tree of CQueries within your server is your taste. 
All clients I know till now are just treating a flat list of algorithms. GIFT 
is used to receiving just flat lists of algorithms, and then turn them into a 
tree using the algorithm-type tag.

> (Don't get me wrong if I sound finical, I'm just on the way completing
> the puzzle.)

Ugh. Given that you are in Germany, maybe we could do some telephoning. You 
sound like someone very patient doing a discussion that is difficult to lead 
by e-mail for reasons of slowness of the medium. I also got a webcam here, 
then we even can exchange drawings (but I would have to reboot under another 
OS).

I hope we are moving in the right direction...
Cheers,
Wolfgang



reply via email to

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