Data Model for Resources and Registries

This page collects information related to modeling entities that are described in Registries.

Modeling Activities

Work on a Resource data model was started as one of the earliest activities of the working group in 2003. The first working draft of the Resource Metadata (RM) specification in late 2002 defined a core set of metadata and formed the basis of a core data model realized by the VOResource XML schema. Early modeling activity can be found in the Early Work section below.

The model that emerged centered on a core model that includes the concepts defined in the RM. Extensions to the core could be defined to handle specific types of resources, particularly standard services. The sections below attempt to show the current state of the model.

Working Draft schemas based on this model have supported working registries that successfully trade resource descriptions and export them to VO applications since 2003. In 2005 at the Kyoto Interop meeting, as part of an effort to move to a version 1.0 of all key Registry standards, a special modeling "tiger team" was formed to revisit the model for service resources and to create an extension for describing applications. The membership included KevinBenson, SebastienDerriere, PaulHarrison, TonyLinde, RayPlante, GuyRixon, and AurelienStebe. Their discussions were carried out on the reg-dm mailing list.

Two discussion pages summarize the tiger team work:

• RegDMServices
• RegDMApplications

The Core Resource Model

This section will provide an updated picture of the core Resource model.

Services Model

Applications Model

(Somewhat Out-of-Date) Early Work

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
  • any type of organisation
• site
  • a single location
• 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