[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] Re: Region query for MRML/GIFT

From: Pruet Boonma
Subject: Re: [help-GIFT] Re: Region query for MRML/GIFT
Date: Fri, 1 Mar 2002 02:48:44 +1100
User-agent: Mutt/1.3.27i


On Thu, Feb 28, 2002 at 05:01:13PM +0100, Wolfgang M?ller wrote:

> > So I think that it is better to devide the query step into two stages,
> > query image list and query segment for request image. Therefore, the
> > clients that don't understand the segment information will not go
> > further into the second stage.
> OK. So probably I overlooked, surely I misinterpreted something when reading 
> your example code. So what you want to do is to request segments by URL? Yes 
> of course, this is a possible way to go.
> (snipped)

Sorry, I think that I didn't make it clear. The segment information is
the region boundary code(from mpeg-7) that define each segment in the
image. So it's not separated images. So, it's true that we request
segment information by the image URL(s) because it's only one way that can
refer to a particular image, AFAIK.

> > Anyway, I think that, from the get-algorithm/get-collection stage, the
> > client already know whatever the server supports segment. So the client
> > should not send any segment to the server which not support segment.
> So it is rather an "and" condition in the query paradigm, right?

Yeah, I think so.

> Your points are all valid, but some of them miss IMHO the "philosophy" of 
> MRML. The idea of MRML is to transmit data in a way that as much as possible 
> is understandable by as many clients/log analyzers etc. as possible. Yes, you 
> can do negotiation between client and server, you can find the right 
> query-paradigm settings, you can tell your client not to query servers that 
> don't know a certain query paradigm etc. . However e.g. if you want to make a 
> pool of user interaction logs, a log analyzer would throw away all your 
> interaction data if it does not know your extension. I think MRML extensions 
> should try to behave in a way that even incomplete implementations can gather 
> as much as possible from the data, safely ignore the rest, and still be 
> functional.
Yes, the MRML philosophy is the important issue that I very need your
help. From the MRML technical paper I think that in some case, we can
extend it by add a attribute, this will work for single value data.
However, the segmentdata is multiple values, for example, more than one
segment can be selected in a image. So I think that we should extend by
add new child tag to <query-step>, which is <user-segment-query-list>
(the wording can be changed later).

However, if there are another way which is better than this way, it will
be very welcome. 

I will update my Dia diagrame soon, to change some query-paradigm

About debian package, I've added new debian package for 0.1.7 at my homepage,
 after fix the problem (./configure; make distclean). However, I still need
 some advice from you in many way, such as, should we separate it into
two or three packages, common+server+dev, or just create a big one.
Moreover, I've created a .tgz from .deb, so you can have a look at the
file structure and which file should be included. My server URL is


> Cheers,
> Wolfgang
> _______________________________________________
> help-GIFT mailing list
> address@hidden

reply via email to

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