1.  Image and Full-text transfer under Z39.50 -- issues for
 2.  discussion
 3.
 4.  (A) the "thinking machines" problem. documents are segmented
 5.  into chunks, 1.... N.  A search returns a document ID and the
 6.  ID of the most relevant chunk.  To subsequently get the
 7.  document do another search with the DOCID and CHUNK ID as
 8.  parameters, returns a chunk.  Could specify CHUNK ID ranges
 9.  to get surrounding context.  Can page through document by
 10. varying CHUNK numbers.
 11.
 12. The basic model here is that a server segments a document
 13. (or other object) into pieces, and you can ask for it
 14. piece by piece (at the cost of another search).  This avoids
 15. all the problems of big objects without protocol mods as
 16. long as the server segments these objects into chunks that
 17. are smaller than the maximum record size.
 18.
 19. Note one advantage of this is that chunks can have data
 20. sensitive meanings (eg paragraphs) rather than just being
 21. fixed-size segments.
 22.
 23. I think this approach can also handle most of the problems
 24. of images discussed in the recent note from CMU.
 25.
 26. One issue that we do need to talk about is transfer formats
 27. for chunks, be they images or textual information.
 28.
 29. (B) Image specific issues.  As we look at general-purpose
 30. image servers, however.  I think that a lot of additional
 31. question arise, and I'm not clear how Z39.50 can (or should)
 32. be extended to address them.
 33.
 34. It would seem to me that given an image stored in a server,
 35. I should be able to ask the server to perform a number of
 36. manipulations on the image prior to sending it to me, both 
 37. in order to conserve bandwidth, to conserve memory in the
 38. client, and also so that code to do these functions does not
 39. have to be replicated in client software.  In some cases, the
 40. server may even have special hardware to assist in these 
 41. functions which the client probably won't have.
 42.
 43.    Functions:
 44.         select format:  CCITT G3, CCITT G4, JPEG, uncompress, etc.
 45.         decimate to specific pixel density
 46.         reduce depth of pixels (eg 24 bit color to 8 bit color)
 47.         interpolate the higher pixel density (?)
 48.         select subset of images.
 49.         transform image (eg compute FFT)
 50.         convert greyscale to monochrome
 51.
 52.    In addition, it may be desirable to receive a progressive
 53.    transmission of the image.  One way to structure this would
 54.    be to define the sequence of images under a specific
 55.    progressive transmission scheme as a series of transforms
 56.    on the image, eg PROGRESSIVE1, PROGRESSIVE2, etc., and to
 57.    have the client explicitly request each additional level of
 58.    detail as a separate request.
 59.
 60.    There seem to be a couple of different ways that we might
 61.    proceed to accommodate this within Z39.50's overall
 62.    structure, which may also be useful within other contents.
 63.    One idea would be to include a new function, transform
 64.    result set.  This could be used for anything from sorting
 65.    or ranking a result set in traditional bibliographic
 66.    contexts to decimating a result set that contained an
 67.    image on a remote server.  To use this with images, however,
 68.    there needs to be a way to get an image into a result
 69.    set (for example, assign each image a unique ID; you find
 70.    the image by some other search which gives you the ID, then
 71.    do a search on that ID in the image database, giving you
 72.    a 1-image result set).  If we go this route, then we can just
 73.    set up a registry of transforms.  There are lots of details
 74.    to be worked out, however.
 75.
 76.    Question:  Is this a reasonable overall approach?
 77.