Difference: RegDMServices (1 vs. 25)

Revision 252012-06-26 - root

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

Schemas and Example Instances (Release Candidate 8 2006-06-13)

Release candidate 8 is available from RegUpgradeSummer2006.

Schemas and Example Instances (Release Candidate 7 2006-05-16)

All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

Several of the examples use STC which requires sia-v1.30.xsd and xlink.xsd.

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.


META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822877" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="54333" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147822911" name="organisation.xml" path="organisation.xml" size="1951" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822979" name="collection.xml" path="collection.xml" size="5039" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823012" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7241" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823054" name="conesearch.xml" path="conesearch.xml" size="3434" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823123" name="registry.xml" path="registry.xml" size="2544" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823298" name="siastd.xml" path="siastd.xml" size="6283" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823329" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13287" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823370" name="sia.xml" path="sia.xml" size="7550" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823440" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="27670" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823481" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="8959" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823520" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="5882" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823583" name="webform.xml" path="webform.xml" size="1905" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823625" name="webservice.xml" path="webservice.xml" size="2586" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823655" name="sia2ver.xml" path="sia2ver.xml" size="3989" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="release candidate 7" date="1147822738" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="44735" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r7)" date="1147822780" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="164091" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147823696" name="catalog.xml" path="catalog.xml" size="7833" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1147795038" name="collection-stc.xml" path="collection-stc.xml" size="4546" user="RayPlante" version="1.1"

Revision 242006-06-13 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.
Added:
>
>

Schemas and Example Instances (Release Candidate 8 2006-06-13)

Release candidate 8 is available from RegUpgradeSummer2006.

 

Schemas and Example Instances (Release Candidate 7 2006-05-16)

All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

Several of the examples use STC which requires sia-v1.30.xsd and xlink.xsd.

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822877" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="54333" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147822911" name="organisation.xml" path="organisation.xml" size="1951" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822979" name="collection.xml" path="collection.xml" size="5039" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823012" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7241" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823054" name="conesearch.xml" path="conesearch.xml" size="3434" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823123" name="registry.xml" path="registry.xml" size="2544" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823298" name="siastd.xml" path="siastd.xml" size="6283" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823329" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13287" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823370" name="sia.xml" path="sia.xml" size="7550" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823440" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="27670" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823481" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="8959" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823520" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="5882" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823583" name="webform.xml" path="webform.xml" size="1905" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823625" name="webservice.xml" path="webservice.xml" size="2586" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823655" name="sia2ver.xml" path="sia2ver.xml" size="3989" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="release candidate 7" date="1147822738" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="44735" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r7)" date="1147822780" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="164091" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147823696" name="catalog.xml" path="catalog.xml" size="7833" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1147795038" name="collection-stc.xml" path="collection-stc.xml" size="4546" user="RayPlante" version="1.1"

Revision 232006-05-16 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.
Changed:
<
<

Schemas and Example Instances

>
>

Schemas and Example Instances (Release Candidate 7 2006-05-16)

  All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml
Added:
>
>
Several of the examples use STC which requires sia-v1.30.xsd and xlink.xsd.
 

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="release candidate 6" date="1147601343" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="56878" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
>
>
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822877" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="54333" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147822911" name="organisation.xml" path="organisation.xml" size="1951" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147822979" name="collection.xml" path="collection.xml" size="5039" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823012" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7241" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="release candidate 7" date="1147823054" name="conesearch.xml" path="conesearch.xml" size="3434" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823123" name="registry.xml" path="registry.xml" size="2544" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823298" name="siastd.xml" path="siastd.xml" size="6283" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823329" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13287" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823370" name="sia.xml" path="sia.xml" size="7550" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="h" comment="" date="1147823440" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="27670" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823481" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="8959" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1147823520" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="5882" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823583" name="webform.xml" path="webform.xml" size="1905" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823625" name="webservice.xml" path="webservice.xml" size="2586" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147823655" name="sia2ver.xml" path="sia2ver.xml" size="3989" user="RayPlante" version="1.3"
 
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1147656011" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="45200" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r6)" date="1147656053" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="93005" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="release candidate 7" date="1147822738" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="44735" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r7)" date="1147822780" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="164091" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147823696" name="catalog.xml" path="catalog.xml" size="7833" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="" comment="" date="1147795038" name="collection-stc.xml" path="collection-stc.xml" size="4546" user="RayPlante" version="1.1"

Revision 222006-05-16 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

Schemas and Example Instances

All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="release candidate 6" date="1147601343" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="56878" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1147656011" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="45200" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r6)" date="1147656053" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="93005" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="" comment="" date="1147795038" name="collection-stc.xml" path="collection-stc.xml" size="4546" user="RayPlante" version="1.1"
 

Revision 212006-05-15 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

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:
Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="release candidate 6" date="1147601343" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="56878" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1147656011" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="45200" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r6)" date="1147656053" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="93005" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"

Revision 202006-05-15 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

Schemas and Example Instances

All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="release candidate 6" date="1147601343" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="56878" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1147189188" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="25615" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples" date="1147189251" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="36173" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="" date="1147656011" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="45200" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples (r6)" date="1147656053" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="93005" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"

Revision 192006-05-14 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

Schemas and Example Instances

All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

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.


<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="release candidate 6" date="1147601343" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="56878" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1147189188" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="25615" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples" date="1147189251" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="36173" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"

Revision 182006-05-09 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.
Added:
>
>

Schemas and Example Instances

 
Added:
>
>
All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip.
 
Added:
>
>
Individual examples:
Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
catalog.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml
 
Added:
>
>
 

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.
Deleted:
<
<

Schemas and Example Instances

All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

Individual examples:

Schema Sample intance
VOResource-v1.0.xsd organisation.xml
webform.xml
webservice.xml
VODataService-v1.0.xsd collection.xml
ConeSearch-v1.0.xsd conesearch.xml
SIA-v1.0.xsd sia.xml
sia2ver.xml
VORegistry-v1.0.xsd registry.xml
VOStandard-v1.0.xsd siastd.xml

Proposal #3

 
<--  
-->

META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
 
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189733" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189771" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189833" name="conesearch.xml" path="conesearch.xml" size="3105" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189863" name="registry.xml" path="registry.xml" size="2474" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189903" name="siastd.xml" path="siastd.xml" size="6213" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="" date="1147189939" name="sia.xml" path="sia.xml" size="7216" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147189969" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190001" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="h" comment="for unified proposal" date="1147190033" name="sia2ver.xml" path="sia2ver.xml" size="3656" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="h" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
 
META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
Added:
>
>
META FILEATTACHMENT attr="" comment="" date="1147189188" name="VOResource-v1.0-local.tar.gz" path="VOResource-v1.0-local.tar.gz" size="25615" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="unified proposed schemas and examples" date="1147189251" name="VOResource-v1.0-local.zip" path="VOResource-v1.0-local.zip" size="36173" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="for unified proposal" date="1147189799" name="catalog.xml" path="catalog.xml" size="7745" user="RayPlante" version="1.1"
 

Revision 172006-05-09 - RayPlante

 
META TOPICPARENT name="RegistryModel"
Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

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

ServiceDataModel.gif

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.
Specific Interface types:
  • 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.

    Changed:
    <
    <
  1. <interface> is now a child of <capability>.
  2. >
    >
  3. Connecting capability with multiple interfaces: <interface> is now a child of <capability>.
  4.   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.
    Changed:
    <
    <
  5. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.
  6. >
    >
  7. Minimual Interface descriptions: For all currently defined Interface sub-types, the only required content is the accessURL element; all other content is optional.
  8.  
    Changed:
    <
    <
  9. 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.
  10. >
    >
    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.
     
    Added:
    >
    >
  11. Multiple Capabilities: A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

  12. 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.
  13.  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.
    Changed:
    <
    <
  14. The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.
  15. >
    >
  16. 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.
  17.   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.

    Changed:
    <
    <
  18. 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.
  19. >
    >
  20. 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.
  21.   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
    Changed:
    <
    <
  22. detailed information about the standard interface, like required input parameters.
  23. >
    >
  24. detailed information about the standard interface, like required input parameters. This can be used to support workflow agents and automated GUI-builders.
  25.  
    Added:
    >
    >
    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.

     
    Changed:
    <
    <
  26. The <interface> element will include an optional version attribute which identifies which version of the standard that interface supports.
  27. >
    >
  28. Identifying versions: The <interface> element will include an optional version attribute which identifies which version of the standard that interface supports.
  29.  
    • 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.
    Changed:
    <
    <
  30. 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.
  31. >
    >
  32. 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.
  33.  

    Schemas and Example Instances

    All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

    Individual examples:

    Schema Sample intance
    VOResource-v1.0.xsd organisation.xml
    webform.xml
    webservice.xml
    VODataService-v1.0.xsd collection.xml
    ConeSearch-v1.0.xsd conesearch.xml
    SIA-v1.0.xsd sia.xml
    sia2ver.xml
    VORegistry-v1.0.xsd registry.xml
    VOStandard-v1.0.xsd siastd.xml

    Proposal #3


    <--  
    -->

    META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
    META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
    META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
    META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
    META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"

    Revision 162006-05-08 - RayPlante

     
    META TOPICPARENT name="RegistryModel"
    Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
    Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

    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

    ServiceDataModel.gif

    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.
    Added:
    >
    >
    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.
    Added:
    >
    >
    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.
    Added:
    >
    >
    Specific Interface types:
    • 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.
     

    Deleted:
    <
    <
     

    Detailed Summary of Proposed Changes

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

      Changed:
      <
      <
    1. <interface> is now a child of <capability>.
    2. >
      >
    3. <interface> is now a child of <capability>.
    4.   This solidifies the connection between a set of capability metadata and the interfaces that provide that capability.

        Changed:
        <
        <
      • 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.
      • >
        >
      • 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.
      •  
        Changed:
        <
        <
      • 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 <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.
      •  
        Changed:
        <
        <
      • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
      • >
        >
      • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
      •  
        Changed:
        <
        <
      • A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.
      • >
        >
      • A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.
      •  
        Changed:
        <
        <
      • 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.
      • >
        >
      • 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.
      •  
        Changed:
        <
        <
        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.
        >
        >
        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.
         
          Changed:
          <
          <
        • 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.
        • >
          >
        • 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.
        •  
          Changed:
          <
          <
        • 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.
        • >
          >
        • 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.
        •  
          Changed:
          <
          <
        • 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.
        • >
          >
        • 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.
        •  

        • The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.
        • Changed:
          <
          <
          For example, the SimpleImageAccess capability type does not require that the required ParamHTTP interface be included inside the capability description.
          >
          >
          For example, the SimpleImageAccess capability type does not require that the required ParamHTTP interface be included inside the capability description.
           
          Changed:
          <
          <
          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.
          >
          >
          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.
           
          Changed:
          <
          <
          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.
          >
          >
          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.
           
          Changed:
          <
          <
        • 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.
        • >
          >
        • 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:
            Changed:
            <
            <
          • 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.
          • >
            >
          • 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.
          • Changed:
            <
            <
          • 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 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
          • Changed:
            <
            <
          • detailed information about the standard interface, like required input parameters.
          • >
            >
          • detailed information about the standard interface, like required input parameters.
          •  
            Changed:
            <
            <
          • The <interface> element will include an optional "version" attribute which identifies which version of the standard that interface supports.
          • >
            >
          • The <interface> element will include an optional version attribute which identifies which version of the standard that interface supports.
          •  
              Changed:
              <
              <
            • the meaning of the version attribute is undefined when the parent <capabiltiy> element's standardID is not given.
            • >
              >
            • the meaning of the version attribute is undefined when the parent <capabiltiy> element's standardID is not given.
            •  
              Changed:
              <
              <
            • 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.
            • >
              >
            • 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.
            •  
              Changed:
              <
              <
            • 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.
            • >
              >
            • 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.
            •  
              Changed:
              <
              <
            • 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.
            • >
              >
            • 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.
            •  

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Proposal #3


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"

              Revision 152006-05-08 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              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

              ServiceDataModel.gif

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

              Detailed Summary of Proposed Changes

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

              1. <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. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

              5. 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.
              6. 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.
              7. 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.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Proposal #3


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
              Changed:
              <
              <
              META FILEATTACHMENT attr="" comment="UML model" date="1147105719" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="24580" user="RayPlante" version="1.1"
              >
              >
              META FILEATTACHMENT attr="" comment="UML model" date="1147121671" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="21423" user="RayPlante" version="1.2"
               

              Revision 142006-05-08 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              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.

              Added:
              >
              >

              UML Model Diagram

              ServiceDataModel.gif

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

               

              Detailed Summary of Proposed Changes

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

              1. <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. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

              5. 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.
              6. 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.
              7. 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.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Proposal #3

              Deleted:
              <
              <

              Model Diagram

               
              Deleted:
              <
              <
               
              <--  
              -->
              Deleted:
              <
              <

              • UML model:
                ServiceDataModel.gif
               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="UML model" date="1147105719" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="24580" user="RayPlante" version="1.1"

              Revision 132006-05-08 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              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.

              Detailed Summary of Proposed Changes

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

              1. <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. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

              5. 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.
              6. 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.
              7. 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.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Proposal #3

              Model Diagram


              <--  
              -->

              Added:
              >
              >
              • UML model:
                ServiceDataModel.gif
               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
              Added:
              >
              >
              META FILEATTACHMENT attr="" comment="UML model" date="1147105719" name="ServiceDataModel.gif" path="ServiceDataModel.gif" size="24580" user="RayPlante" version="1.1"
               

              Revision 122006-05-08 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              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.

              Detailed Summary of Proposed Changes

              Added:
              >
              >
              This section enumerates the specific changes to the VOResource schema since version 0.10.
               
              1. <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. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

              5. 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.
              6. 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.
              7. 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.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Proposal #3

              Model Diagram


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"

              Revision 112006-05-08 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              Changed:
              <
              <
              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.
              >
              >
              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.
              Changed:
              <
              <

              Summary of Proposed Changes

              >
              >

              Overview of the New Service Model

               
              Changed:
              <
              <

              Proposal #1

              >
              >
              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".
               
              Added:
              >
              >
              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.

              Detailed Summary of Proposed Changes

               
              1. <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.
              Changed:
              <
              <
            • The <interface> (or interfaces) that are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
            • >
              >
            • 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.
            • A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

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

            • 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.
            • Changed:
              <
              <
              A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three advantages:
              >
              >
              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.
              Added:
              >
              >
            • 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.
            •  
              Deleted:
              <
              <
              This idea, however, is controversial (see issues below).
               

            • 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.
            • Changed:
              <
              <
            • Assuming 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.
            • >
              >
            • 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.
            •  
              Changed:
              <
              <
            • A service that supports multiple versions of, say, SIA, would include multiple <interface>s of the proper type (and with std="true") inside the SimpleImageAccess <capability> element.
            • >
              >
            • 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.
            •  
              Added:
              >
              >
            • 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.
            •  
              Changed:
              <
              <

              Schemas and Example Instances

              >
              >

              Schemas and Example Instances

                All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml
              Deleted:
              <
              <

              P1 Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              P2 Issues and Concerns

              • seems no way to identify the capability represented by any given interface without saying that every interface represented by a service must support every capability within that service definition, so a service which has both a cone search and a skynode interface has to be registered twice
               

              Proposal #3

              Model Diagram


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"

              Revision 102006-05-02 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Proposal #1

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              P1 Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              P2 Issues and Concerns

              • seems no way to identify the capability represented by any given interface without saying that every interface represented by a service must support every capability within that service definition, so a service which has both a cone search and a skynode interface has to be registered twice
              Added:
              >
              >

              Proposal #3

               

              Model Diagram


              <--  
              -->
              Added:
              >
              >
               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
              Added:
              >
              >
              META FILEATTACHMENT attr="" comment="for proposal #3" date="1146578544" name="VORes-v1.0r5.zip" path="VORes-v1.0r5.zip" size="33285" user="RayPlante" version="1.1"
               

              Revision 92006-04-27 - TonyLinde

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Proposal #1

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml
              Changed:
              <
              <

              Issues and Concerns

              >
              >

              P1 Issues and Concerns

               
              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                
              Changed:
              <
              <

              Issues and Concerns

              >
              >

              P2 Issues and Concerns

              Added:
              >
              >
              • seems no way to identify the capability represented by any given interface without saying that every interface represented by a service must support every capability within that service definition, so a service which has both a cone search and a skynode interface has to be registered twice
               

              Model Diagram


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"

              Revision 82006-04-27 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Proposal #1

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              Issues and Concerns

              Model Diagram


              <--  
              -->
              Deleted:
              <
              <
              • : for proposal #1
               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"

              Revision 72006-04-27 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Proposal #1

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              Changed:
              <
              <
              SIA-v1.0.xsd sia.xml
              >
              >
              SIA-v1.0.xsd sia.xml
              sia2ver.xml
               
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              Issues and Concerns

              Model Diagram


              <--  
              -->
              Added:
              >
              >
              • : for proposal #1
               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
              Added:
              >
              >
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146115885" name="sia2ver.xml" path="sia2ver.xml" size="3782" user="RayPlante" version="1.1"
               

              Revision 62006-04-27 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Proposal #1

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Schemas and Example Instances

              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              Changed:
              <
              <
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              >
              >
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
               
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              Issues and Concerns

              Model Diagram


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              Changed:
              <
              <
              META FILEATTACHMENT attr="" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              >
              >
              META FILEATTACHMENT attr="h" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
              Added:
              >
              >
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113212" name="webform.xml" path="webform.xml" size="1866" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1146113232" name="webservice.xml" path="webservice.xml" size="2512" user="RayPlante" version="1.1"
               

              Revision 52006-04-25 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              Deleted:
              <
              <
              (as proposed by Registry Data Model tiger team)
               
              Added:
              >
              >

              Proposal #1

               
              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.
              Changed:
              <
              <

              Minority report

              >
              >

              Schemas and Example Instances

              Deleted:
              <
              <
              (proposal submitted by Aurelien Stebe who disagrees with the above approach)
               
              Added:
              >
              >
              All of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz.

              Individual examples:

              Schema Sample intance
              VOResource-v1.0.xsd organisation.xml
              webform.xml
              webservice.xml
              VODataService-v1.0.xsd collection.xml
              ConeSearch-v1.0.xsd conesearch.xml
              SIA-v1.0.xsd sia.xml
              VORegistry-v1.0.xsd registry.xml
              VOStandard-v1.0.xsd siastd.xml

              Issues and Concerns

              • "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis.
              • forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 25 Apr 2006

              Proposal #2

              Aurelien Stebe
               
              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                
              Added:
              >
              >

              Issues and Concerns

               

              Model Diagram

              Deleted:
              <
              <

              Schemas and Example Instances

               
              Deleted:
              <
              <
              [Examples:
              • registry record
              • service with ConeSearch and SIA capabilities]
               
              Deleted:
              <
              <

              Open Issues

               
              Deleted:
              <
              <
              • interfaces inside of capability
              • registering standards

              -- RayPlante - 07 Mar 2006

               
              <--  
              -->
              Deleted:
              <
              <

               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"

              Revision 42006-04-25 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              (as proposed by Registry Data Model tiger team)

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Minority report

              (proposal submitted by Aurelien Stebe who disagrees with the above approach)

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                
                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

              Model Diagram

              Schemas and Example Instances

              [Examples:

              • registry record
              • service with ConeSearch and SIA capabilities]

              Open Issues

              • interfaces inside of capability
              • registering standards

              -- RayPlante - 07 Mar 2006


              <--  
              -->
              Added:
              >
              >

               
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
              Added:
              >
              >
              META FILEATTACHMENT attr="" comment="Sample XSDs and instances for proposal #1" date="1145952812" name="VORes-v1.0.tar.gz" path="VORes-v1.0.tar.gz" size="21656" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952929" name="VOResource-v1.0.xsd" path="VOResource-v1.0.xsd" size="52101" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145952970" name="organisation.xml" path="organisation.xml" size="1881" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953015" name="collection.xml" path="collection.xml" size="3049" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953049" name="ConeSearch-v1.0.xsd" path="ConeSearch-v1.0.xsd" size="7210" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953166" name="conesearch.xml" path="conesearch.xml" size="3989" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="for proposal #1" date="1145953202" name="registry.xml" path="registry.xml" size="2543" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953233" name="siastd.xml" path="siastd.xml" size="2108" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953299" name="SIA-v1.0.xsd" path="SIA-v1.0.xsd" size="13256" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953333" name="sia.xml" path="sia.xml" size="8268" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953361" name="VODataService-v1.0.xsd" path="VODataService-v1.0.xsd" size="21533" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="h" comment="" date="1145953413" name="VORegistry-v1.0.xsd" path="VORegistry-v1.0.xsd" size="9010" user="RayPlante" version="1.1"
              META FILEATTACHMENT attr="" comment="" date="1145953440" name="VOStandard-v1.0.xsd" path="VOStandard-v1.0.xsd" size="3748" user="RayPlante" version="1.1"
               

              Revision 32006-03-24 - TonyLinde

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.
              Changed:
              <
              <

              Summary of Proposed Changes #1

              >
              >

              Summary of Proposed Changes

              Added:
              >
              >
              (as proposed by Registry Data Model tiger team)
               
              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.
              Changed:
              <
              <

              Summary of Proposed Changes #2

              >
              >

              Minority report

              Added:
              >
              >
              (proposal submitted by Aurelien Stebe who disagrees with the above approach)
               
              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".
              Deleted:
              <
              <
               
              • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
              • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              Deleted:
              <
              <
               
            • The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

              All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

            • Deleted:
              <
              <
               
            • Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
            • Deleted:
              <
              <
               This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

              Here is what an instance of SIA or Registry service entry would look like :

              Deleted:
              <
              <
               
              <resource xsi:type="Service">
                .............
                <interface xsi:type="ParamHTTP">
              	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
              	 ..............
                </interface>
                <capability xsi:type="SIACapability">
              	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
              	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
              	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
              	 <maxImageExtent> ..... </maxImageExtent>
              	 ..............
                </capability>
              </resource>
              
              Deleted:
              <
              <
               
              <resource xsi:type="Service">
                .............
                <interface xsi:type="WebService">
              	 <accessURL use="full"> http://...../..../Search </accessURL>
                </interface>
                <interface xsi:type="WebService">
              	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                </interface>
                <interface xsi:type="ParamHTTP">
              	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
              	 ..............
                </interface>
                <capability xsi:type="RegistryCapability">
              	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
              	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
              	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
              	 <managedAuthority> ..... </managedAuthority>
              	 <managedAuthority> ..... </managedAuthority>
                </capability>
              </resource>
              
              Deleted:
              <
              <
              -- AurelienStebe - 24 Mar 2006
               

              Model Diagram

              Schemas and Example Instances

              [Examples:

              • registry record
              • service with ConeSearch and SIA capabilities]

              Open Issues

              • interfaces inside of capability
              • registering standards

              -- RayPlante - 07 Mar 2006


              <--  
              -->

              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"

              Revision 22006-03-24 - AurelienStebe

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.
              Changed:
              <
              <

              Summary of Proposed Changes

              >
              >

              Summary of Proposed Changes #1

               
              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.
              Added:
              >
              >

              Summary of Proposed Changes #2

              1. <Capability> is now an abstract element and an optional child of <Service>.
                <Service> now has two multiple optional child elements : <Interface> and <Capability>. Both elements need to be extended and declared in the resource document using "xsi:type".

                • <Interface> is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
                • <Capability> is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
              2. The <Capability> extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in <Capability> extensions, but a different element type may be used.

                All service specifications will be expected to provide its specific <Capability> extension to allow for that service entries to be specified in a Registry.

              3. Standard services are now identified by the presence of its corresponding <Capability> extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of <Capability> using "xsi:type".
              4. This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : VOResource.xsd, SIA.xsd, VORegistry.xsd

                Here is what an instance of SIA or Registry service entry would look like :

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../siap.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="SIACapability">
                	 <siaEndpointURL version="1.0"> http://...../..../siap0.jsp </siaEndpointURL>
                	 <siaEndpointURL version="1.1"> http://...../..../siap1.jsp </siaEndpointURL>
                	 <maxQueryRegionSize> ..... </maxQueryRegionSize>
                	 <maxImageExtent> ..... </maxImageExtent>
                	 ..............
                  </capability>
                </resource>
                

                <resource xsi:type="Service">
                  .............
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Search </accessURL>
                  </interface>
                  <interface xsi:type="WebService">
                	 <accessURL use="full"> http://...../..../Harvest </accessURL>
                  </interface>
                  <interface xsi:type="ParamHTTP">
                	 <accessURL use="base"> http://...../..../oai.jsp </accessURL>
                	 ..............
                  </interface>
                  <capability xsi:type="RegistryCapability">
                	 <searchEndpointURL version="0.9"> http://...../..../Search </searchEndpointURL>
                	 <searchEndpointURL version="0.10"> http://...../..../Search </searchEndpointURL>
                	 <harvestEndpointURL version="0.10"> http://...../..../Harvest </harvestEndpointURL>
                	 <managedAuthority> ..... </managedAuthority>
                	 <managedAuthority> ..... </managedAuthority>
                  </capability>
                </resource>
                

                -- AurelienStebe - 24 Mar 2006

               

              Model Diagram

              Schemas and Example Instances

              [Examples:

              • registry record
              • service with ConeSearch and SIA capabilities]

              Open Issues

              • interfaces inside of capability
              • registering standards

              -- RayPlante - 07 Mar 2006


              <--  
              -->
              Added:
              >
              >
              META FILEATTACHMENT attr="" comment="VOResource schema for Proposition #2" date="1143217211" name="VOResource-v0.10-prop2.xsd" path="VOResource-v0.10-prop2.xsd" size="41967" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="SIA schema for Proposition #2" date="1143217229" name="SIA-v0.7-prop2.xsd" path="SIA-v0.7-prop2.xsd" size="13090" user="AurelienStebe" version="1.1"
              META FILEATTACHMENT attr="" comment="VORegistry schema for Proposition #2" date="1143217247" name="VORegistry-v0.3-prop2.xsd" path="VORegistry-v0.3-prop2.xsd" size="2544" user="AurelienStebe" version="1.1"
               

              Revision 12006-03-07 - RayPlante

               
              META TOPICPARENT name="RegistryModel"
              Jumps: IvoaResReg :: reg-dm mail archive :: ResourceMetadata
              Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg

              Registry Data Model: Services

              This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.

              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.

              Summary of Proposed Changes

              1. <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 are mandated by standard service described by the <capability> will have an attribute called "std" which will be set to "true".
                • The different sub-types of interfaces (WebService, WebBrowser, ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the <interface> element.
              2. A Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.

              3. 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.
              4. 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.

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

                A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered. This provides three 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.
                This idea, however, is controversial (see issues below).
              6. 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.
                • Assuming 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 std="true") inside the SimpleImageAccess <capability> element.

              Model Diagram

              Schemas and Example Instances

              [Examples:

              • registry record
              • service with ConeSearch and SIA capabilities]

              Open Issues

              • interfaces inside of capability
              • registering standards

              -- RayPlante - 07 Mar 2006


              <--  
              -->
               
              This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
              Ideas, requests, problems regarding TWiki? Send feedback