NVO Metadata Working Group Meeting
2002-07-11  Thursday 11am ET (10am CT, 9am MT, 8am PT, 4pm Strasbourg)

Attendees: Gretchen Greene, John Good, Jonathan McDowell, Ray Plante, 
	   Arnold Rots, Doug Tody, Ed Shaya

Minutes:

1. Roll call & News

(Minutes assigned to John Good.)

      Ray:    mySRB service useful for galaxy morphology demo:

	         1) registry service for metadata
	         2) user data publication (e.g. for data sharing)

      Doug:   mySRB is more for shared data storage and for
              managing data collections.

      Ray:    Regan says SRB can be used for service registration.
              Also, using it means we don't have to set up a database
              ourselves.  This will provide us with the experience to
              how it is best applied to long-term infrastructure.

      Doug:   Premature to be looking at it for managing 
              web services.

      Ray:  Agreed.

   
2. Simple Image Access Document

      Arnold: What is the objective of this document, discussion

      Doug:   Objective: provide something simple that meets needs of
              first year demos, but which is consistent with long term
              vision. 

      Ray:    Discussion: to elicit suggestions for changes to be made
	      to the document that will allow people to start implementing.
	 
      Arnold: This is a little rushed.

      Ray:    Would another week help?

      Arnold: Yes.
      
      Ray:    Roadmap: plan for 2 more iterations.  First done this
	      week, integrating initial comments; second after next
	      week's meeting, giving opportunity for closer scrutiny.
	      Some initial implementation activity can get started
	      between the two versions.

	      [General agreement.]

      Doug:   As long as it doesn't get much more complicated.

      Gretchen:  We already have an implementation for DSS that is
              pretty close, based on the current version.

      Ray:    Long term: Need consistent usage patterns in query and response
      
      Doug:   Cone search was early prototype and deals with
	      somewhat different parameters.

      Arnold: How long is this expected to live?

      Doug:   It's a stepping stone but should been seen as
	      an expendable prototype.
      
      Arnold: Therefore no need for consistency.

      Doug:   Agreed.  There will probably be at least a couple
	      more major iterations.

	      [General agreement that the minutes should include
	       the statement that these services are explicitly
	       to be considered throwaway.]
      
      Ray:    Consistency with the cone search is not a strong
	      requirement; important to be quick to implement and
	      to support demos.

	      [General agreement that this is really two services:
	       image metadata query and image retrieval]

      Ray:    This week's discussion should concentrate on internal
	      consistency.
      

      Doug:   Let's go through the specification [I was involved in
	      the discussion and there was more give and take, so
	      individual voices are harder to track].

      Doug began summary of major sections:
          2. Requirements for Compliance
	  3. Image Service Types

      John:   do we have examples of each of the types that we expect to
              implement this spec?

      Doug:   Yes, I think.  Sloan expects initially to implement as
              an atlas archive.  

      Skyview - mosaic service, 2MASS - cutout service, 
      ADIL - generic image archive

	      First part:  Image query resulting in VOTable (metadata)
	      Second part: Image retrieval resulting in image data

	      Image query (metadata)

      John:    Comment: Region definition loose (e.g. projection
	       indeterminant) [I will give some reference to our
	       existing approach]

		 Overlap parameter discussion (call for email 
		 discussion)

		 metadata query (Ray): (call for email discussion)

      Ray/Doug:  We went back and forth about whether IM (which
	       constrains how the images intersect with the region)
	       was important enough to include.  Is it?

      Doug:    Would rather not include it as it complicates the
               implementation on the server, plus it is expected that
               the client will have to do some analysis on the
               returned table to figure out which images are actually
               desired.  

      Ray:     It's actually not difficult to implement on the server
	       side (the ADIL does this now).  It's much easier than
	       analyzing WCSs on the client side; the practical
	       requirements on the client are reduced if hits can be
	       easily be filtered as part of the query.  

               Is this important to retain?

      John:    Yes.  Our service does this (with additional options);
	       however, it's not easy to do it right.

      Ray:     The ADIL implementation is only approximate.  However,
	       it's very useful filtering out large scale (atlas)
	       images (e.g. all-sky images) when you are really only
	       interested in a small isolated region.  

      ...

      As the hour approached the end, Doug gave an very appreviated
      highlighting of remaining sections.

Ray reiterated road map:  Doug will work on a new version this
weekend.  Over the next week, folks will scrutinize the document more
closely.  Particular areas needing comments:
   *  metadata used through out the spec.
   *  staging service: is this sufficient?  (John)
Send comments to metadata list, and we will discuss them further next
week.  Another version will come out the following week.  Meanwhile,
eager souls are encouraged to get started on implementation now.