1. May 18, 2006IVOA Interoperability Meeting Fine-grained vs. Coarse-grained Registries or How much detail about a resource should be stored in a registry?

2. May 18, 2006IVOA Interoperability Meeting What information? Catalog/Table columns name, type, unit, ucd Generic Interface information Input parameters: name, type, unit, ucd Return type For a standard service, this information can be gotten from the service itself Note: all current registry implementations support this information

3. May 18, 2006IVOA Interoperability Meeting Drivers Fine-grained: more information in registries Workflow building agents need detailed information Enough information to correctly call services –Present GUI, choices to users –e.g. service input parameters Discover specific services based on detailed information –e.g. table column UCD (phot.mag;em.IR.K) Coarse-grained: less information in registries Registry curation invariably requires human inspection Registry curation prefers less information: the more information, the greater the effort required to maintain it –Greater opportunity for error Detailed information (e.g. columns) may change over time –can get out of sync with registry –The service itself is a better source of this information Registry curation prefers fewer registry records Allows more records to be human-inspected

4. May 18, 2006IVOA Interoperability Meeting What types of resources? A course-grained approach: Prefer larger aggregations as resources Organisations Data Collections e.g. archive-level: XMM, 2MASS, Sloan, HST Services Too fine-grained Images Catalog Records People Use Query services to drill down to this detail SIA, ConeSearch, SkyNode, etc. ivo://myorg/myresource?mydataset Where do these fall? Catalogs – particularly small catalogs If these are too-fine grained, how do we find them?

5. May 18, 2006IVOA Interoperability Meeting Consequences/Questions What is the purpose of the registry? How does it fit into the process of data discovery? To what extent can it be automated? How does it fit into automated workflow generation? If some info is too fine-grained for the registry, is there another way to discover based on this info? Do we have sufficient tools/services to discover based on fine-grained info? How does a registry handle information it does not wish/unable to support? Does support simply mean index for searching? How do manage the growth of our registries? How do we minimize junk? How do we keep search results from looking like junk? What is the impact on applications that use the registry? Are there some guiding principles we can adopt?

6. May 18, 2006IVOA Interoperability Meeting Principles We must allow innovation Not every registry needs to be the same in features and character Must allow a registry to specialize to the needs of its community Innovation can feed back into the IVOA process We must preserve data providers role as data curator and science-enabler The VO is not… a data warehouse one-size-fits-all solution, replacement for mission-specific solutions Providers need incentives to participate To support VO standards To take an active role in curating registry records, services To link in mission-specific capabilities

7. May 18, 2006IVOA Interoperability Meeting Practical Questions Do we continue to allow detailed table and service interface information in registry records? Is it sufficient to make this information optional? Can a registry support discovery based on fine-grained info without supporting it in our standard schemas? What is required of a registry that harvests detailed info it does not support? (searching, export) Should we develop alternate mechanisms for discovery based on fine- grained info? How do registries deal with (non-standard) schema extensions it doesnt understand Can they be handled as generic Resources? What is required when exporting the record? (What is the consequence for applications?) What should a registry do when client attempts to search on a non- standard or unsupported metadatum?