(r19) RegDMServices < IVOA

IVOA Web>IvoaResReg>RegistryModel>RegDMServices (revision 19) (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.  

---++ UML Model Diagram

<img src="%ATTACHURLPATH%/ServiceDataModel.gif" alt="ServiceDataModel.gif"  width="747" height="729"  />

---+++ Semantic Definitions of Classes

   $ Resource: Any entity or component of a VO application that is describable and identifiable by a IVOA Identifier.
      * <dl><dt>validationLevel: </dt><dd> A numeric grade describing the quality of the resource's core description, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study. </dd></dl>
   $ Service: a resource that can be invoked by a client to perform some action on its behalf.
   $ <nop>SkyService: a Service that returns or operates on astronomical data that has an associated coverage of the Sky.
   $ <nop>TabularSkyService: A <nop>SkyService that returns or operates on tabular data.
   $ Capability: a description of what the service does (in terms of context-specific behavior), and how to use it (in terms of an interface).
      * <dl><dt>validationLevel: </dt><dd> A numeric grade describing the quality of the capability description and interface, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study. </dd></dl>
      * <dl><dt>description:</dt><dd> A human-readable description of what this capability provides as part of the over-all service.</dd></dl>
      * <dl><dt>standardID:</dt><dd>  A URI identifier for a service standard.</dd></dl>
   $ <nop>SimpleImageAccess: a capability that conforms to the SIAP standard.
   $ Interface: a description of how to call the service to access a capability.
      * <dl><dt>accessURL:</dt><dd>The URL (or base URL) that a client uses to access the service. </dd></dl>
      * <dl><dt>version:</dt><dd>The version of a standard interface specification that this interface complies with. </dd></dl>
      * <dl><dt>role:</dt><dd>A tag name the identifies the role the interface plays in the particular capability.  If the value is equal to "std" or begins with "std:", then the interface refers to a standard interface defined by the standard referred to by the capability's standardID attribute.  </dd></dl>
Specific Interface types:
   * <dl><dt>WebBrowser:</dt><dd>A (form-based) interface intended to be accesed interactively by a user via a web browser.</dd></dl>
   * <dl><dt>WebService:</dt><dd>A Web Service that is describable by a WSDL document.</dd></dl>
   * <dl><dt>ParamHTTP:</dt><dd> An interface invoked via an HTTP Query (either Get or Post) with a set of arguments consisting of keyword name-value pairs.</dd></dl>

---++ Schemas and Example Instances

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

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]] <br> [[%ATTACHURL%/catalog.xml][catalog.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]] |


---++ Detailed Summary of Proposed Changes

This section enumerates the specific changes to the VOResource schema since [[IVOA.VOResourceV010][version 0.10]].

<ol>
   <li> *Connecting capability with multiple interfaces*: =&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:<i>name</i>", 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> *Minimual Interface descriptions*:  For all currently defined =Interface= sub-types, the only required content is the =<nop>accessURL= element; all other content is optional.

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

   <li> *Multiple Capabilities:*  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> *Service with Capabilities:*  We no longer describe standard services (like SIA) as sub-classes of the =Service= resource class; instead, we describe a generic =Service= resource and show its support for a standard protocol via the presence of the associated standard capability description.  Thus, a generic service can support multiple standard protocols (via multiple =&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> *Extra validation required:*  The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.

For example, the =<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> *Identifying standard capabilities:*  The base =Capability= type will include an optional attribute called =standardID= which holds an unambiguous identifier (URI) for the standard that the service adheres to.  For standard services that have defined a specialized subclass of =Capability=, this attribute will be fixed to the identifier for that standard.  

For IVOA standards, this URI would be an IVOA identifier; this would require that a resource describing a standard to be registered.  This provides several advantages:
      <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.  This can be used to support workflow agents and automated GUI-builders.  </li>
            </ul></li>
      </ul>

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

   <li> *Identifying versions:* 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 <code>&lt;interface&gt;</code>s of the proper type (and with =role="std"=) inside the =<nop>SimpleImageAccess= <code>&lt;capability&gt;</code> element.  </li>
   </ul></li>

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

<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
gif	ServiceDataModel.gif	r2 r1	manage	20.9 K	2006-05-08 - 20:54	RayPlante	UML model
xsd	VORegistry-v0.3-prop2.xsd	r1	manage	2.5 K	2006-03-24 - 16:20	AurelienStebe	VORegistry schema for Proposition #2
xsd	VOResource-v0.10-prop2.xsd	r1	manage	41.0 K	2006-03-24 - 16:20	AurelienStebe	VOResource schema for Proposition #2
gz	VOResource-v1.0-local.tar.gz	r1	manage	25.0 K	2006-05-09 - 15:39	RayPlante
zip	VOResource-v1.0-local.zip	r1	manage	35.3 K	2006-05-09 - 15:40	RayPlante	unified proposed schemas and examples
xml	catalog.xml	r1	manage	7.6 K	2006-05-09 - 15:49	RayPlante	for unified proposal
Topic revision: r19 - 2006-05-14 - 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