Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example Instances | |||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||
< < | All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. | ||||||||||||||||||||||||||||||||||||||||||||||||
> > | All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. | ||||||||||||||||||||||||||||||||||||||||||||||||
Individual examples:
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
|