(r11) RegDMServices < IVOA

IVOA Web>IvoaResReg>RegistryModel>RegDMServices (revision 11) (raw view)~~EditAttach~~
<small>Jumps:  IvoaResReg :: [[http://www.ivoa.net/forum/registry/][reg-dm mail archive]] :: ResourceMetadata
<br> Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg </small>

---+!! Registry Data Model:  Services

This page summarizes a new model for describing services proposed by the Registry-DM tiger team to be incorporated into version 1.0 of the VOResource family of schemas.  

__Contents__
%TOC%
---

---++ Goals

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

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

---++ Overview of the New Service Model

*The new model provides a way to bring together various related service capabilities together into one logical Resource record.*  In most cases, these capabilities are related in that they all access the same underlying dataset or collection.  For example, the description for a single service that accesses a catalog might describe both its support for the <nop>SkyNode standard protocol (one "capability") as well as for <nop>ConeSearch (another "capability").  Whereas we used to register support for these standards as separate services, we can now register these together in one record.  This can not only reduce the number of registry records, but also reduce redundent information, making the information easier to maintain.  We sometimes refer to this approach as a *"service with capabilities"*.  

This approach manifests itself in the following structural features:
   * a Service record may contain multiple =&lt;capability&gt;= elements, 
   * a =&lt;capability&gt;= element may contain one or more &lt;interface&gt; elements.  

And as suggested above, *we no longer identify a standard service like SIA as a specific type of Resource* (i.e. =&lt;resource xsi:type="SimpleImageAccess"&gt;=) *but as a generic type of resource with an SIA capability* (i.e. =&lt;capability xsi:type="SimpleImageAccess"&gt;=).

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

<ol>
   <li> &lt;interface&gt; is now a child of &lt;capability&gt;. 

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

   <ul>
      <li> A &lt;capability&gt; element may include multiple &lt;interface&gt; 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 &lt;capability&gt; may include both a <nop>WebService interface and an interactive <nop>WebBrowser interface; the latter simply provides a GUI wrapping of the soap interface.  </li>

      <li> The &lt;interface&gt; (or interfaces) that is mandated by the service standard indicated by the &lt;capability&gt; 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.  </li>

      <li> The different sub-types of interfaces (<nop>WebService, <nop>WebBrowser, <nop>ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the &lt;interface&gt; element.
    </ul></li>

   <li> A Service resource class no longer contains &lt;interface&gt; elements as direct children; instead it contains one or more &lt;capabiltiy&gt; elements.  

   <li> We no longer describe standard services (like SIA) as sub-classes of the Service resource class; instead, we describe a generic Service resource and show its support for a standard protocol via the presence of the associated standard capability description.  Thus, a generic service can support multiple standard protocols (via multiple &lt;capabiltiy&gt; 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 <nop>ConeSearch capability, a VOStore capability, etc.

   <ul>
      <li> Standard protocols that need to define specialized capability metadata do so in a subclass of the Capability type.  The xsi:type mechanism is used to include the specialized capability element into the service description.</li>

      <li> The Service subclasses, <nop>SkyService and <nop>TabularSkyService, are retained to include descriptions of coverage and the tables engaged by the service.  An SIA Capability should be a part of a <nop>TabularSkyService.</li>

      <li> Services (or more precisely, service capabilities) that have no specialized capability metadata defined--in particular, non-standard services--use the base &lt;capabiltiy&gt; element with no xsi:type attribute to hold the description of the interface.  The optional &lt;description&gt; child of &lt;capabiltiy&gt; may be used to provide a human-readable description of what the capability provides.  </li>
   </ul></li>

   <li> The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.

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

This enables a uniform way of identifying interface types:  via the value of the &lt;interface&gt; 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 <nop>TabularSkyService; this will also be checked by a specialized VO registry validator.  </li>

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

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

   <li> The &lt;interface&gt; element will include an optional "version" attribute which identifies which version of the standard that interface supports.  

   <ul>
      <li> the meaning of the version attribute is undefined when the parent &lt;capabiltiy&gt; element's standardID is not given. </li>

      <li> When the standardID holds an IVOA identifier, the description of the standard pointed to by that identifier would include a list of recognized versions.  The value of the version attribute must match one of the recognized versions.  </li>

      <li> A service that supports multiple versions of, say, SIA, would include multiple &lt;interface&gt;s of the proper type (and with role="std") inside the <nop>SimpleImageAccess &lt;capability&gt; element.  </li>
   </ul></li>

   <li> The VOResource schemas will now set elementDefaultForm="unqualified".  This greatly reduces the need for namespace prefixes in instance documents.  Resource record authors need not have to pay so close attention to which elements belong to which namespaces.  In particular, simple XPaths (that will appear in ADQL queries to the registries) will be much simpler.  Only types given in xsi:type attributes will still require namespace prefixes.  </li>
</ol>

---++ Schemas and Example Instances

All of the schemas and examples can be downloaded together:  [[%ATTACHURL%/VORes-v1.0.tar.gz][VORes-v1.0.tar.gz]].

Individual examples:
| Schema | Sample intance |
| [[%ATTACHURL%/VOResource-v1.0.xsd][VOResource-v1.0.xsd]] |   [[%ATTACHURL%/organisation.xml][organisation.xml]] <br>  [[%ATTACHURL%/webform.xml][webform.xml]] <br>  [[%ATTACHURL%/webservice.xml][webservice.xml]] |
| [[%ATTACHURL%/VODataService-v1.0.xsd][VODataService-v1.0.xsd]] |  [[%ATTACHURL%/collection.xml][collection.xml]] |
| [[%ATTACHURL%/ConeSearch-v1.0.xsd][ConeSearch-v1.0.xsd]] |  [[%ATTACHURL%/conesearch.xml][conesearch.xml]] |
| [[%ATTACHURL%/SIA-v1.0.xsd][SIA-v1.0.xsd]] |  [[%ATTACHURL%/sia.xml][sia.xml]] <br> [[%ATTACHURL%/sia2ver.xml][sia2ver.xml]]|
| [[%ATTACHURL%/VORegistry-v1.0.xsd][VORegistry-v1.0.xsd]] |  [[%ATTACHURL%/registry.xml][registry.xml]] |  
|[[%ATTACHURL%/VOStandard-v1.0.xsd][VOStandard-v1.0.xsd]] |  [[%ATTACHURL%/siastd.xml][siastd.xml]] |


---+++ Proposal #3

   * schemas & examples: [[%ATTACHURL%/VORes-v1.0r5.zip][VORes-v1.0r5.zip]]

---++ Model Diagram




<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
xsd	SIA-v0.7-prop2.xsd	r1	manage	12.8 K	2006-03-24 - 16:20	AurelienStebe	SIA schema for Proposition #2
xsd	VORegistry-v0.3-prop2.xsd	r1	manage	2.5 K	2006-03-24 - 16:20	AurelienStebe	VORegistry schema for Proposition #2
gz	VORes-v1.0.tar.gz	r1	manage	21.1 K	2006-04-25 - 08:13	RayPlante	Sample XSDs and instances for proposal #1
zip	VORes-v1.0r5.zip	r1	manage	32.5 K	2006-05-02 - 14:02	RayPlante	for proposal #3
xsd	VOResource-v0.10-prop2.xsd	r1	manage	41.0 K	2006-03-24 - 16:20	AurelienStebe	VOResource schema for Proposition #2
Topic revision: r11 - 2006-05-08 - RayPlante
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema