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

[Wolfgang Müller]

Hi again,
> 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.

Correct. So I really misunderstood your diagram as I already thought in the 
previous mail. Yes, I think this is a good way to go. 

(snip)

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

Yes, I see this.

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

How about this?

<user-relevance-element image-location="some://url" relevance-level="1">  
  <!-- this is some overall relevance of the image gathered from by the 
client from segments-->
  <user-relevance-segment relevance-level="-1">
  <!--some segment description here -->
  </user-relevance-segment>
</user-relevance-element>
>
> However, if there are another way which is better than this way, it will
> be very welcome.

Please feel free to express your opinions about the above suggestion. I think 
there will be some more iterations. I hope you also find it enjoyable.

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

OK. Keep us posted when it changes.

> 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

This is cool. BTW I did some changes, so that some parts of gift that were 
distributed using the extra_dist automake tag, are now generated in the usual 
fashion. Furthermore there are some *.cc files which are not properly cleaned 
out (which make some of the compile errors. You and I don't get this trouble 
in using CVS, because the not-properly cleaned files are not in CVS, so when 
checking out the sources will be younger than the non-cleaned-out files => 
they are correctly rebuilt). I will try to get 0.1.8 (i.e. the fixed 0.1.7) 
out till monday.

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

Oh, yes, this is a great question. Presently I would opt (at least) for 

Base: everything you need for running the GIFT and indexing a collection
Dev:  everything for doing development (e.g. like gift plugins)

Now the question comes to the Perl client etc. how do we call that, or do we 
integrate it with development for the time being? Suggestions, everybody?

> 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
> http://lulu.mptc.eng.cmu.ac.th:8080/debian/

OK. Cool. I will try to look into that before monday.

Cheers,
Wolfgang


PS: this is sent with some delay, as my provider had massive problems 
yesterday, so I could not log in.