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

[Pruet Boonma]

Hi,

On Tue, Mar 05, 2002 at 09:24:03PM +0100, Wolfgang M?ller wrote:
> Dear Pruet,
> 
> I appreciate a lot our discussion, and I would like to emphasize that anyone 
> is welcome to participate.
> 
> I guess we are still getting repercussions of my initial misunderstanding. I 
> know it sounds silly, but could you make available your initial DIA file 
> *and* the current version, and I look at both versions again? I think most of 
> my misunderstanding is that when reading segment query I was thinking of 
> query-by-segment and I still could not get this out of my head even when you 
> rectified it. Sorry for that.

This is the old one.
http://lulu.mptc.eng.cmu.ac.th:8080/pruet/docs/thesis/xmlmrml1.dia

This is the new one.
http://lulu.mptc.eng.cmu.ac.th:8080/pruet/docs/thesis/xmlmrml.dia

> 
> Now trying to recall what I have seen of the first version you showed to me, 
> and the later ones, I think it might be good to separate two things:
> 
> i) query by segment: here the query as well as the result should be 
> syntactically as close to the "normal" query by example as possible, as I 
> outlined in previous mails. This means a syntax like your example from your 
> last mail:
> 
> <query-result>
>    <query-result-element-list>
>       <query-result-element
>           calculated-similarity="1.000000"
>           image-location="http://localhost/1.jpg";
>           thumbnail-location="...">
>          <query-result-element-segment-list>
>             <query-result-element-segment segment-id="1">
>                <box>
>                 ...
>                </box>
>             </query-result-element-segment >
>             ...
>          </query-result-element-segment-list>
>       </query-result-element>
>    </query-result-element-list>
> </query-result>

I strongly believe that this is the one that I want to do. So, in this
case, it should be an extension of query-step and query-result.

> 
> ii) a simple lookup, where for one image you request more info. In your case 
> these are segments. And all the time we have been talking about segment. Why 
> not use general image or document info? I think this could be useful for all 
> kind of meta data. Could you try modify the "get-segments-by-url"-like syntax 
> into something that uses a common tag for similar things like image size, 
> etc.? I imagine the results be presented like in the example above, but with 
> some tags (also at the second level) indicating that the result is the result 
> of a get-image-info query rather than a normal query result.

I'm not sure that this is a good way to describe complex data, such
as segment data, in this way. It will work very well for simple
meta-data such as image size, image type, image permission or event
image annotation. However, with complicate data like segmentation or
image semantic, I'm still in doubt that it can be done easily this way.

> 
> To sketch this out further I would think about a 
> 
> get-document-info tag (you specify in some attributes what image info [e.g. 
> segments] you would like to have)
Let's try,
//client=>server
<get-image-info-list>
    <get-image-info
     image-location="http://localhost/pic/1.jpg";
     image-thumbnail="..." />
</get-image-info-list>
> 
> and as the response a
> 
> document-info 
> 
> tag (I believe that's quite close to your initial suggestion). People will 
> find out in parsing that there is a segment inside.
//server=>client
<image-info-list>
    <image-info
     image-location="http://localhost/pic/1.jpg";
     image-thumbnail="..." >
        <info-list>
            <info name="size" type="number" value="28000" />
            <info name="type" type="string" value="jpg" />
            <info name="annotation" type="string" value="picture of three big 
trees in the Melbourne Royal Botanic Garden" />
        <info-list />
    </image-info>
</image-info-list>

Ok, you can see that it's very easy to incorporate simple data into info
tag. We can even reuse algorithm property sheet also. 

Now, let's try to put segment data into this scheme.

server=>client
<image-info-list>
    <image-info
     image-location="http://localhost/pic/1.jpg";
     image-thumbnail="..." >
        <info-list>
            <info name="size" type="number" value="28000" />
            <info name="type" type="string" value="jpg" />
            <info name="annotation" type="string" value="picture of three big 
trees in the Melbourne Royal Botanic Garden" />
                        <info name="segment" type="sub">
                <segment-list>
                    <segment segment-id="1">
                        <box>
                        ...
                        </box>
                   </segment >
                ...
                </segment-list>
            </info>
        <info-list />
    </image-info>
</image-info-list>

Ok, you can see that it's possible to put segment data into this scheme.
However, it will make it's more complicate and make exceptions or
special cases in parsing. 

> 
> What do you think about this, would you agree to fleshing this out a bit? 
> Please note that this is not a criticism on your work (especially note again 
> that we are getting closer back to your initial suggestion), but rather an 
> encouragement to make it more reusable.

As I show you, it's possible to do in the second case, however, I think
that maybe it's better to separate segment data into a special case and
threat it specially.

> 
> I will be away from mail the rest of this week, and I am looking forward to 
> finding your suggestions on this list next week.

That's fine. I still have lots of paper work to do. Thank you anyway.

Cheers,
Pruet


> 
> Cheers,
> Wolfgang
>