Registry Use Cases

In general, I see registries being used as a way of narrowing down the
search for data and services to manageable subset of the available
resources.  It is not intended that a registry replicates all data
into a central repository but rather a condensed set of metadata.  How
much a resource reveals itself to a registry (e.g. the granularity of
descriptions) will in large part be controled by the resource itself.

In this set of use cases, I group them into broad catagories
indicating the type thing being located.  A number of variations on
these types are expected.

1)  Locating Data Collections

    Find collections that may contain desired data.
    Example:  tell the ways I can access infrared images of the Orion
                 nebula.

    Return possibilities
      *  the type of resource (e.g. archive, survey, catalog [Hanish 2002])
      *  Collection's Home Page 
      *  a description of supported (access) services 

    Possible Search criteria
      *  the type of resource
      *  type of data included (images, spectra, catalog, ...)
      *  frequency waveband
      *  sky coverage
      *  time coverage
      *  the types of services supported (SIA, Cone search, etc.)
      *  descriptive keywords

2) Locating Services

   A. Data Access Services

      Example: Find all optical, ground-based image archives that
	          support SIA.
	       Find all mosaicing services that cover the north
	          galatic pole.

      Return:
        *  service description (describing supported inputs, outputs,
	     and access URL)

      Possible Search criteria:
        *  type of service
	*  type of data included (images, spectra, catalog, ...)
        *  frequency waveband
        *  sky coverage
        *  time coverage
        *  descriptive keywords
	*  access type (i.e. what level of authorization required; 
	     e.g. public vs. authenticated or proprietary)

   B. Generic/Processing Services

      Examples: Find a name-resolver
		Find a coordinate converter

      Return 
        *  service description 

      Possible Search criteria:
        *  type of service
	*  input/output objects
	*  descriptive keywords
	*  access type (i.e. what level of authorization; 
	     e.g. public vs. authenticated or proprietary)

3) Locating Resources

   This is expected to be less common; however, one may wish to use
   to obtain contact information.  

   Return
     * description of resource
     * contact information
     * URL to Resource's home page

   Possible Search criteria:
     * resource name or identifier
     * descriptive keywords

4) Unique access to Resource, Collection, and Service Descriptions

   It is expected that a client will know exactly what resource or
   service it wants to access.  The client, for example, may have done
   a search previously for optical archives but now knows it wants
   only Space Telecope data.  It should be possible to query the
   registry for a description of a specific resource and be guaranteed
   that only that single description will be returned.  (This is
   typically done via an identifier for the description.)