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

[Wolfgang Müller]

Hi,
(snip)

> Sorry, I belive that I don't agree with you in this case. The information,
> I mean the segment data, should be sent if users request it. For example,
> a user requests 20 images and he needs segment data for only 1 image. Why
> we have to send segment data for all image ? It should be very ineffective
> if the segment data is very big, such as free-form segment.

> 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)
>
> 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?

>
> > The same, make your segment descriptions that are sent as result,
> > children of query-result-element. Otherwise, normal QBE clients like
> > Snake charmer won't see a single result. However, the segmentation info
> > is rather an extension to the image and not the image itself.
>
> This one will not happend becuase that kind of client will not request
> <query-step> with query-type="segmented" as I proposed.
>
> > What I find is really missing is the possibility to treat segments that
> > have not been transmitted by the server (i.e. have the user draw the
> > segments). I guess this will be easy to add to the MRML, and more
> > difficult on the server side.
>
> It is not included in this stage, however I strongly believe that it can
> be included in user-relevance-element-list. 
Sure.

> By the way, I and David
> didn't look further into this field yet.

I see.

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.

Cheers,
Wolfgang