Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example Instances (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: STC which requires sia-v1.30.xsd and xlink.xsd.Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
| |||||||||||||||||||||||||||||||||||||||||||||||||||
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: STC which requires sia-v1.30.xsd and xlink.xsd.Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
| |||||||||||||||||||||||||||||||
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: | |||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||
> > | Several of the examples use STC which requires sia-v1.30.xsd and xlink.xsd. | ||||||||||||||||||||||||||||||
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
| |||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. Individual examples:Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example Instances | |||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||
< < | All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. | ||||||||||||||||||||||||||||||||||||||||||||||||
> > | All of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. | ||||||||||||||||||||||||||||||||||||||||||||||||
Individual examples:
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. Individual examples:Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
| |||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VOResource-v1.0-local.tar.gz, VOResource-v1.0-local.zip. Individual examples:Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
<--
| |||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
| |||||||||
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: | ||||||||
Added: | |||||||||
> > | |||||||||
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
| |||||||||
Deleted: | |||||||||
< < | Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
| ||||||||
<--
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
| |||||||||
Added: | |||||||||
> > |
| ||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10. | |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | <interface> is now a child of <capability> . | ||||||||||||||||||||||||||||||||||||||||||
> > | <interface> is now a child of <capability> . | ||||||||||||||||||||||||||||||||||||||||||
This solidifies the connection between a set of capability metadata and the interfaces that provide that capability.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements. | ||||||||||||||||||||||||||||||||||||||||||
> > | Interface sub-types, the only required content is the accessURL element; all other content is optional. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | 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. | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
> > | Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements.
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.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||||
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: | |||||||||||||||||||||||||||||||||||||||||||
< < | 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. | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||||
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: | |||||||||||||||||||||||||||||||||||||||||||
< < | <interface> element will include an optional version attribute which identifies which version of the standard that interface supports. | ||||||||||||||||||||||||||||||||||||||||||
> > | <interface> element will include an optional version attribute which identifies which version of the standard that interface supports. | ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | 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. | ||||||||||||||||||||||||||||||||||||||||||
> > | 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 InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
| |||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||
> > | Specific Interface types:
| ||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10. | |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <interface> is now a child of <capability> . | ||||||||||||||||||||||||||||||||||||||||||
This solidifies the connection between a set of capability metadata and the interfaces that provide that capability.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | WebService , WebBrowser , ParamHTTP , etc.) are still differentiated via an xsi:type attribute to the <interface> element. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | Service resource class no longer contains <interface> elements as direct children; instead it contains one or more <capabiltiy> elements. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | Capability type. The xsi:type mechanism is used to include the specialized capability element into the service description. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <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: | |||||||||||||||||||||||||||||||||||||||||||
< < | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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. | ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | referenceURL element). This is important for non-IVOA standards in which the location of the relevent standard documents is not widely known. | ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <interface> element will include an optional version attribute which identifies which version of the standard that interface supports. | ||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <capabiltiy> element's standardID is not given. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | <interface> s of the proper type (and with role="std" ) inside the SimpleImageAccess <capability> element. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||
> > | 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 InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
UML Model DiagramSemantic Definitions of Classes
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
<--
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries. | |||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||
> > | UML Model DiagramSemantic Definitions of Classes
| ||||||||||||||||||||||||||||||||||||||||||
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
| |||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | Model Diagram | ||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||
<--
| |||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
Detailed Summary of Proposed ChangesThis section enumerates the specific changes to the VOResource schema since version 0.10.
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
Model Diagram<--
| |||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Overview of the New Service ModelThe new model provides a way to bring together various related service capabilities together into one logical Resource record. In most cases, these capabilities are related in that they all access the same underlying dataset or collection. For example, the description for a single service that accesses a catalog might describe both its support for the SkyNode standard protocol (one "capability") as well as for ConeSearch (another "capability"). Whereas we used to register support for these standards as separate services, we can now register these together in one record. This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain. We sometimes refer to this approach as a "service with capabilities". This approach manifests itself in the following structural features:
<resource xsi:type="SimpleImageAccess"> ) but as a generic type of resource with an SIA capability (i.e. <capability xsi:type="SimpleImageAccess"> ).
The new model addresses all of the above goals, including being able to indicate what version of a standard the service supports as well as showing support for non-standard interfaces. It also formally proposes that we register standards as a type of resource, which provides several potentially helpful uses. Service implementations can thus use an IVOA Identifier to indicate support for a standard protocol. This in turn can lead registry users/developers from service records supporting a standard capability to the actual standard document that describes its interface. It provides a place to keep detailed descriptions of standard interfaces (useful to workflow and automated GUI builders) without replicating this information in all the implementation records.
Finally, this model raises the the ongoing issue of "coarse- vs. fine-grained" resources and the amount of detail we include in our descriptions. The desire to support auotmated workflows encourages more detail, while concerns over maintanence issues prefer less detail. To help accommodate both sides of the issue, the new model pushes more detailed service description information to be optional. This way, one project can encourage, for example, a high level of detail in its registry without adversely affecting the other registries.
Detailed Summary of Proposed Changes | |||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > | This section enumerates the specific changes to the VOResource schema since version 0.10. | ||||||||||||||||||||||||||||||||||||||||
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Proposal #3
Model Diagram<--
|
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
GoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
| |||||||||||||||||||||||||||||||||||||||||
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:
<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 | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
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: | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < | This idea, however, is controversial (see issues below). | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||
> > | | ||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
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: | |||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < | P1 Issues and Concerns
Proposal #2Aurelien Stebe
<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
| ||||||||||||||||||||||||||||||||||||||||
Proposal #3
Model Diagram<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed ChangesProposal #1
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:P1 Issues and Concerns
Proposal #2Aurelien Stebe
<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
| |||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||
> > | Proposal #3
| ||||||||||||||||||||||||||||||||||||||
Model Diagram<--
| |||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||
> > | |||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed ChangesProposal #1
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples: | |||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||
< < | Issues and Concerns | ||||||||||||||||||||||||||||||||||||||
> > | P1 Issues and Concerns | ||||||||||||||||||||||||||||||||||||||
Proposal #2Aurelien Stebe
<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: | |||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||
Model Diagram<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed ChangesProposal #1
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:Issues and Concerns
Proposal #2Aurelien Stebe
<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 ConcernsModel Diagram<--
| |||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed ChangesProposal #1
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:
| |||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||
Issues and Concerns
Proposal #2Aurelien Stebe
<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 ConcernsModel Diagram<--
| |||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed ChangesProposal #1
Schemas and Example InstancesAll of the schemas and examples can be downloaded together: VORes-v1.0.tar.gz. Individual examples:
| |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Issues and Concerns
Proposal #2Aurelien Stebe
<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 ConcernsModel Diagram<--
| |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed Changes | |||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||
< < | (as proposed by Registry Data Model tiger team) | ||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||
> > | Proposal #1 | ||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||
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:
Issues and Concerns
Proposal #2Aurelien Stebe | ||||||||||||||||||||||||||||||||
<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:
| ||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||
< < | Open Issues | ||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||
<--
| |||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed Changes(as proposed by Registry Data Model tiger team)
Minority report(proposal submitted by Aurelien Stebe who disagrees with the above approach)
<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 DiagramSchemas and Example Instances[Examples:
Open Issues
<--
| |||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
| ||||||||
Changed: | ||||||||
< < | Summary of Proposed Changes #1 | |||||||
> > | Summary of Proposed Changes | |||||||
Added: | ||||||||
> > | (as proposed by Registry Data Model tiger team) | |||||||
| ||||||||
Changed: | ||||||||
< < | Summary of Proposed Changes #2 | |||||||
> > | Minority report | |||||||
Added: | ||||||||
> > | (proposal submitted by Aurelien Stebe who disagrees with the above approach) | |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
| ||||||||
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 DiagramSchemas and Example Instances[Examples:
Open Issues
<--
|
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
| ||||||||
Changed: | ||||||||
< < | Summary of Proposed Changes | |||||||
> > | Summary of Proposed Changes #1 | |||||||
| ||||||||
Added: | ||||||||
> > | Summary of Proposed Changes #2
<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 DiagramSchemas and Example Instances[Examples:
Open Issues
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg Registry Data Model: ServicesThis page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team. ContentsGoalsThe model for describing services was revisited to address several needs. In particular, a revised model needs to allow:
Summary of Proposed Changes
Model DiagramSchemas and Example Instances[Examples:
Open Issues
<--
|