RegistryModel < IVOA

IVOA Web>IvoaResReg>RegistryModel (2006-03-07, RayPlante) (raw view)

---+ Data Model for Resources and Registries

%TOC%

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 [[http://www.ivoa.net/Documents/latest/RM.html][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 [[#Somewhat_Out_of_Date_Early_Work][Early Work]] section below.  

The model that emerged centered on a core model that includes the concepts defined in the [[http://www.ivoa.net/Documents/latest/RM.html][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 [[InterOpMay2005ResReg][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 [[http://www.ivoa.net/forum/reg-dm/][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 <br> __Note:__ service sub-types such as <nop>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* <br> __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 <br> __Note:__ properties of the copy will represent the period a mirror is updated, the date/time a snapshot was taken etc. <br> __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. <br> __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
%ATTACHURL%/Resource.gif

---+++ Registry model
%ATTACHURL%/Registry.gif

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
pdf	NewServiceModelUML.pdf	r1	manage	40.7 K	2006-02-13 - 22:24	RayPlante	UML model for Services w/SIA example

Topic revision: r7 - 2006-03-07 - RayPlante

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema