Registry Data Model: Services

This 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.

Contents

Goals

The model for describing services was revisited to address several needs. In particular, a revised model needs to allow:

1. multiple version support -- it is necessary for the standard services to describe not only what version of a standard they are compliant with but to allow support for multiple versions simultaneously. It would be conventient if a support for multiple versions could be described within a single resource record.
2. multiple endpoints covering different parts of a logical interface -- Supported use cases must be allowed:
   • the Registry service interface has 2 components: searching and harvesting; each can have their own endpoint and feature a different class of interface (soap web service vs. the standard OAI interface).
   • a service such as a SkyNode can not only support standard SkyNode interface, it might also support other interfaces to functionality that can be used in conjunction with the SkyNode interface but which are described by a different standards. Possible examples include VOStore or the standard support services.
3. including in the description of a service additional, non-standard interfaces -- providing via a different endpoint URL additional interfaces that are not part of the standard but which access essentially the same underlying data or information.
4. clarifying the association between service capability metadata and interface that supports the capability -- previously, when a service description included multiple interfaces, it was not clear which of those interfaces was associaed with the specific service capability metadata. The association between capability and interface needs to be made clearer.

Overview of the New Service Model

The 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:

• a Service record may contain multiple <capability> elements,
• a <capability> element may contain one or more <interface> elements.

And as suggested above, we no longer identify a standard service like SIA as a specific type of Resource (i.e. <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 Diagram

Semantic Definitions of Classes

Resource

Any entity or component of a VO application that is describable and identifiable by a IVOA Identifier.

• validationLevel:

  A numeric grade describing the quality of the resource's core description, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.

Service

a resource that can be invoked by a client to perform some action on its behalf.

SkyService

a Service that returns or operates on astronomical data that has an associated coverage of the Sky.

TabularSkyService

A SkyService that returns or operates on tabular data.

Capability

a description of what the service does (in terms of context-specific behavior), and how to use it (in terms of an interface).

• validationLevel:

  A numeric grade describing the quality of the capability description and interface, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.

• description:

  A human-readable description of what this capability provides as part of the over-all service.

• standardID:

  A URI identifier for a service standard.

SimpleImageAccess

a capability that conforms to the SIAP standard.

Interface

a description of how to call the service to access a capability.

• accessURL:

  The URL (or base URL) that a client uses to access the service.

• version:

  The version of a standard interface specification that this interface complies with.

• role:

  A tag name the identifies the role the interface plays in the particular capability. If the value is equal to "std" or begins with "std:", then the interface refers to a standard interface defined by the standard referred to by the capability's standardID attribute.

• WebBrowser:

  A (form-based) interface intended to be accesed interactively by a user via a web browser.

• WebService:

  A Web Service that is describable by a WSDL document.

• ParamHTTP:

  An interface invoked via an HTTP Query (either Get or Post) with a set of arguments consisting of keyword name-value pairs.

Detailed Summary of Proposed Changes

This section enumerates the specific changes to the VOResource schema since version 0.10.

1. Connecting capability with multiple interfaces: <interface> is now a child of <capability>.

   This solidifies the connection between a set of capability metadata and the interfaces that provide that capability.

   • A <capability> element may include multiple <interface> children. This is interpreted to mean that each interface provides access to the same (logical) capability and has essentially the same behavior. As an example, a <capability> may include both a WebService interface and an interactive WebBrowser interface; the latter simply provides a GUI wrapping of the soap interface.
   • The <interface> (or interfaces) that is mandated by the service standard indicated by the <capability> will have an attribute called role which will be set to "std". If the standard specifies more than one interface for the capability, the role attribute will have value of "std:name", where name is a differenciating label defined by the standard.
   • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
2. Minimual Interface descriptions: For all currently defined Interface sub-types, the only required content is the accessURL element; all other content is optional.

   This minimizes the necessity of including redundant information that in practice can usually be assumed when dealing with a standard service like SIA. Registrants may include optional information to indicate, for example in the case of SIA, support for optional parameters or non-standard parameters.

3. Multiple Capabilities: A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

4. Service with Capabilities: We no longer describe standard services (like SIA) as sub-classes of the Service resource class; instead, we describe a generic Service resource and show its support for a standard protocol via the presence of the associated standard capability description. Thus, a generic service can support multiple standard protocols (via multiple <capabiltiy> elements) simultaneously.

   Another way to look at this is that we no longer describe an SIA service; rather, we describe a service with an SIA capability. That same service can also have a ConeSearch capability, a VOStore capability, etc.

   • Standard protocols that need to define specialized capability metadata do so in a subclass of the Capability type. The xsi:type mechanism is used to include the specialized capability element into the service description.
   • The Service subclasses, SkyService and TabularSkyService, are retained to include descriptions of coverage and the tables engaged by the service. An SIA capability should be a part of a TabularSkyService.
   • Services (or more precisely, service capabilities) that have no specialized capability metadata defined--in particular, non-standard services--use the base <capabiltiy> element with no xsi:type attribute to hold the description of the interface. The optional <description> child of <capabiltiy> may be used to provide a human-readable description of what the capability provides.
5. Extra validation required: The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.

   For example, the SimpleImageAccess capability type does not require that the required ParamHTTP interface be included inside the capability description.

   This enables a uniform way of identifying interface types: via the value of the <interface> element's xsi:type. Enforcing the inclusion of the required interface types will be done outside the context of a Schema-validating parser using a specialized VO registry validator.

   Similarly, the schemas will not attempt to enforce, for example, that an SIA capability appear only within the context of a TabularSkyService; this will also be checked by a specialized VO registry validator.

6. Identifying standard capabilities: The base Capability type will include an optional attribute called standardID which holds an unambiguous identifier (URI) for the standard that the service adheres to. For standard services that have defined a specialized subclass of Capability, this attribute will be fixed to the identifier for that standard.

   For IVOA standards, this URI would be an IVOA identifier; this would require that a resource describing a standard to be registered. This provides several advantages:

   • By not defining a specialized Capability sub-type, one lowers the cost for supporting the capability both within a registry and in registry clients; the standardID attribute then becomes the way to identify the standard capability.
   • We leverage the existing registry framework for ensuring standard IDs are unique and unambiguous.
   • The resource record that describes the standard provides a way for users to find the definition of the standard (via the referenceURL element). This is important for non-IVOA standards in which the location of the relevent standard documents is not widely known.
   • The standard record provides a place to include other information (some of which might other wise be repeated in all the records describing implementations of the standard). In particular:
     • the current set of endorsed versions
     • detailed information about the standard interface, like required input parameters. This can be used to support workflow agents and automated GUI-builders.

   Applications may still use the xsi:type to identify standard capabilities when appropriate.

   Finally, we note that we are minimizing the reliance on registered standard records in the core schema as this a new idea that has not been exercised in practice.

7. Identifying versions: The <interface> element will include an optional version attribute which identifies which version of the standard that interface supports.
   • the meaning of the version attribute is undefined when the parent <capabiltiy> element's standardID is not given.
   • When the standardID holds an IVOA identifier, the description of the standard pointed to by that identifier would include a list of recognized versions. The value of the version attribute must match one of the recognized versions.
   • A service that supports multiple versions of, say, SIA, would include multiple <interface>s of the proper type (and with role="std") inside the SimpleImageAccess <capability> element.
8. Reduced use of namespace prefixes: The VOResource schemas will now set elementDefaultForm="unqualified". This greatly reduces the need for namespace prefixes in instance documents. Resource record authors need not have to pay so close attention to which elements belong to which namespaces. In particular, simple XPaths (that will appear in ADQL queries to the registries) will be much simpler. Only types given in xsi:type attributes will still require namespace prefixes.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->