Registry Requirements A. Registration Contents: 1. descriptions of Resources (curation metadata) 2. descriptions of Services: + how to invoke the service, including inputs and outputs + other characteristics of the service; in particular, metadata about the kind of data returned by the service. + compliance details when the service is meant to be an implementation of a standard service. 3. The metadata structures supported by the registry should be consistant with those used by the NVO at large. + XML-based? 4. Need to support a hierarchical notion of resources in order to describe sites that manage multiple collections, missions, services, etc. B. Registry Queries 1. Resources and Services can be searched for based on characteristics. 2. Query results returned in machine-interpretable form 3. Can search for: + resources + services of particular types 4. It should be possible to uniquely retrieve a description of a resource or service either via a unique ID or via a small and predictable set of metadata. C. Registration Process and Registry Evolution 1. It should be easy for data/service provider to register a new service. It should not require one to resubmit information about the resource that was registered before for another service. 2. It should be easy or automatic to update the metadata associated with a resource or service. 3. It should be easy to unregister a resource and service. 4. The registry should expect that registered services may become temporarily unavailable. 5. The registry should account for the possibility that a service will become permanently unavailable without it being explicitly unregistered. 6. The registry system shall support classes of services sharing common characteristics where these shared characteristics can be specified once and then referred to from the implementing services. Updates to shared characteristics can also be made using a single update request to the registry.