Registry Model
Entities
This is the starting point for developing a model of entities with which a registry needs to engage. To start with, we'll simply create a list of 'things' and add definitions to them:
- resource
- an item (with an identity) which is of interest or use to the Virtual Observatory community
- service
- a resource which can be invoked
Note: service sub-types such as ConeSearch or SIAP are still considered to be services, not interfaces
- interface
- a physical, technical interface to a service
- organisation
- site
- publisher
- an organisation responsible for creating and maintaining a resource
- provider
- an organisation responsible for making a service available
Note: since only services are invocable then only they ought to have a provider
- data collection
- a collection of datasets (or other collections)
- copy
- a complete copy of a data collection
Note: properties of the copy will represent the period a mirror is updated, the date/time a snapshot was taken etc.
Note: copies of less than the whole data collection will form new collections with a 'derived from' relationship, much as the results of a query would have
- snapshot
- a copy of a data collection which is never updated
- mirror
- a copy of a data collection which is periodically updated
- dataset
- a single published set of data tables from a science team
- table
- a set of data in which all rows have the same columns (??)
- application
- a collection of functions
- function
- a process that transforms data, generates information, etc.
Note: I'm fairly sure we need both application and function but could do with better definitions
- sky service
- a service that makes one or more data collections available
- tabular sky service
- a specific type of sky service: one which accesses and returns tabular data
- app service
- a service that makes one or more applications available
Model
Draft (simple) models of the terms above:
Resource model
Registry model
