Presentation on theme: "Registries Work Package 2 Requirements, Science Cases, Use Cases, Test Cases Charter: Focus on science case scenarios, and use cases related specifically."— Presentation transcript:
Registries Work Package 2 Requirements, Science Cases, Use Cases, Test Cases Charter: Focus on science case scenarios, and use cases related specifically to VO registries. In particular to develop use cases to define registry requirements
Registry: working definition Means for describing – what computational facilities are available where – How to use them A registry is a queriable service that responds with a structured description of other services Resource and Service defined as in RSMv0.7
Scope Identify Key Science Cases – Drivers for requirements – Registry 'requests' from science cases Use Cases – Representative of envisaged registry useage Test Cases – Test registry implementations Requirements
Work Plan Define scope draft v0.1 - April 11 Key Science Cases draft v0.1 - April 11 – Review of VO science cases - April Use Cases Draft v0.1 - ** Requirements – Toward Registry Requirements – May 09 – Requirements Draft v0.1 - June 28 – Requirements
Key Science Cases AstroGrid: Brown Dwarf Selection – Parameter constrained catalog search AstroGrid: Deep Field Surveys – Coverage constrained data search (Richards) Gamma Ray Burst ++ – 'show me the sky' (McGlynn) AstroVirtel: Luminosity functions of Star Clusters in Nearby Galaxies – Detailed requirements (Micol)
Draft Requirements Registration Contents Registry Queries Registration Process and Registry Evolution
Registration Contents Description of Resources – resource metadata Description of Serices – How to invoke, inputs and outputs – Metadata about returned data – Compliance details when service is a standard service Registry metadata structures should be consistent with those used by IVOA Support hierarchical notion of resources
Registry queries Search for resources based on characteristics Machine readable query results Can search for: resources/services of particular types Should be possible to uniquely retrieve a description of a resource via a unique ID, or via small and predictable set of metadata
Registration Process and Registry Evolution Easy to register a new resource Easy (or automatic) to update resource metadata Easy to unregister Handle temporary unavailability of a resource
Requirements imposed by Science Cases Example queries – Catalogs relevant to galaxy clusters – Catalogs with I,K,J measurements at given sky region – Catalogs of dwarf galaxies with colour or magnitude measurements – Identify resurces relevant to galactic clusters – Identify deep field survey resources – Identify queriable parameters in a given resource
Data Provider Services requests – Coverage: space, time, energy – Resolution, field of view, pixel scale, limiting magnitude – Calibration, data quality – Requests for data of unique provenance (not multiple datasets or catalogs derived from the same observations) –...
Interpretive capabilities Some science case descriptions imply that the registry would have some simple, or complex interpretive capabilities Standard/simple(?) capabilities: – Coordinate transformation – Name resolving – +... (similar to what is done in GLU)
Beyond scope....(?) Unit conversion, or awareness Expert knowledge registries.. International language support Free form queries
Use Cases Need to be extracted from key science cases...
Categorised Use Cases Locating Services – Data access services – Processing services
Data Access Services Return – Service description Possible Search Criteria – Type of resource – Type of data included (image, spectra, catalog...) – Coverage: (space & time) – Descriptive Keywords
Processing Services Examples find a name resolver find a coordinate converter Possible Search Criteria – Type of service – input/output – Descriptive keywords – Access type
Your consent to our cookies if you continue to use this website.