VOResource: an XML Encoding Schema for Resource Metadata
Version 1.0

Status of this document

This is an IVOA Working Draft for review by IVOA members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress."

Comments on this document are due 30 June 2003 for consideration in the next version of this document. They should be sent to registry@ivoa.net, a mailing list with a public archive. General discussion of related technology is also welcome on the Rwp03 wiki site.

A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgements

This document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University, from the UK Particle Physics and Astronomy Research Council (PPARC), and from the Eurpean Commission's Sixth Framework Program via the Optical Infrared Coordination Network (OPTICON).

The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.

XML document validation is a software process that checks that an XML document is not only well-formed XML but also conforms to the syntax rules defined by an XML Schema [Schema] document (see next section).

The eXtensible Markup Language, or XML, is document syntax for marking textual information with named tags and is defined by the World Wide Web Consortium (W3C) Recommendation, XML 1.0 [XML]. The set of XML tag names and the syntax rules for their use is referred to as the document schema. One way to formally define a schema for XML documents is using the W3C standard known as XML Schema [Schema].

This document defines the VOResource schema using XML Schema. The full Schema document is listed in Appendix A. Parts of the schema appear within the main sections of this document; however, documentation nodes have been left out for the sake of brevity.

Reference to specific elements and types defined in the VOResource schema include the namespaces prefix, vr, as in vr:Resource (a type defined in the VOResource schema). Use of the vr prefix in compliant instance documents is not required (see section 2.1); its use in this document is simply to indicate that it is an entity defined in the VOResource schema. References to (local) elements are further labelled by enclosing the name in the XML tag brackets, as in <vr:identifier>.

Contents

• Abstract
• Status of this document
• Acknowledgments
• Conformance-related definitions
• Syntax Notation Using XML Schema
• 1. Introduction
• 2. The VOResource Data Model
  • 2.1. The Schema Namespace and Location
  • 2.2. The Core Structural and Semantic Model
  • 2.3. Extending the VOResource Schema
• 3. The VOResource Metadata
  • 3.1. The Base Resource Type
  • 3.2. Resource Type Extensions: Organisation and Service
• Appendix A: the VOResource XML Schema
• References

1. Introduction

The IVOA Standard, Resource Metadata for the Virtual Observatory [ Hanisch et al. 2004] (hereafter referred to as RM) defines metadata terms for describing resources. The RM defines a resource as:

... VO element that can be described in terms of who curates or maintains it and which can be given a name and a unique identifier. Just about anything can be a resource: it can be an abstract idea, such as sky coverage or an instrumental setup, or it can be fairly concrete, like an organization or a data collection. This definition is consistent with its use in the general Web community as "anything that has an identity" (Berners-Lee 1998, IETF RFC2396). We expand on this definition by saying that it is also describable.

The resource metadata are, then, the terms and concepts that describe a resource in general. The RM defines the terms as well as describes reasonable or allowed values; it does not, however, describe how the terms and values should be encoded. This is because resource metadata may be encoded in several different formats, depending on the context. This document specifically describes an encoding called VOResource.

The primary intended use of VOResource is to provide an XML interchange format for use with resource registries. A registry is a repository of resource descriptions [RM] and is employed by users and applications to discover resources. VOResource can be used to pass descriptions from publishers to registries and then from registries to applications. Another inended use is as a language for services to describe themselves directly. VOResource may be used in other ways, in whole or in part, using the standard XML mechanisms (e.g., import, include).

The VOResource schema provides XML encoding for so-called core metadata from the RM that (with a few exceptions) can apply to al resources; however, it is recognized that a full and useful description of a specific resource will require additional metadata that is relevant only to a resource of its type. Thus, the VOResource schema has been especially designed to be extended. The model for doing this is described in section XX.

Note: The name "VOResource" has in practice had two meanings within IVOA discussions. The first refers specifically to the core XML schema defined by this document. The second refers more broadly to the core schema plus the set of legal extensions. In this document, use of the name "VOResource" corresponds to the first meaning. Reference to the broader set of schemas will be indicated explicitly with the annotating phrase, "and its legal extensions."

2. The VOResource Data Model

The primary use for VOResource, of course, is to describe a resource using the metadata concepts defined in the RM. Here's an example of a VOResource document describing an organisation, the Radio Astronomy Imaging Group at the National Center for Supercomputing Applications.

2 
1
1

3
3

4
4
4
4
4
5
5
5
6
6
6
6
6
6
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

7
7
7
7

<?xml version="1.0" encoding="UTF-8"?>
<resource xsi:type="Organisation"
  xmlns="http://www.ivoa.net/xml/VOResource/v1.0"
  xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0
                      http://www.ivoa.net/xml/VOResource/v1.0">

    <title>NCSA Radio Astronomy Imaging</title>
    <shortName>NCSA-RAI</shortName>
    <identifier>ivo://rai.ncsa/RAI</identifier>

    <curation>
      <publisher ivo-id="ivo://ncsa.uiuc/NCSA">
         National Center for Supercomputing Applications
      </publisher>
      <creator>
        <name>   Dr. Richard Crutcher    </name>
        <logo>
           http://rai.ncsa.uiuc.edu/rai.jpg
        </logo>
      </creator>
      <date>1993-01-01</date>
      <contact>
        <name>Dr. Raymond Plante</name>
	<email>rplante@ncsa.uiuc.edu</email>
      </contact>
    </curation>

    <content>
      <subject>radio astronomy</subject>
      <subject>data repositories</subject>
      <subject>digital libraries</subject>
      <subject>grid-based processing</subject>
      <description>
        The Radio Astronomy Imaging Group at the National Center for
        Supercomputing Applications is focused on applying
        high-performance computing to astronomical research.  Our
        projects include the NCSA Astronomy Digital Image Library, 
        the BIMA Data Archive, the BIMA Image Pipeline, and the
        National Virtual Observatory. 
      </description>
      <referenceURL>http://rai.ncsa.uiuc.edu/</referenceURL>
      <type>Organisation</type>
      <contentLevel>Research</contentLevel>
    </content>

    <facility>Berkeley-Illinois-Maryland Array (BIMA)</facility>
    <facility>
       Combined Array for Research in Millimeter Astronomy (CARMA)
    </facility>

</resource>

1. the VOResource namespace,
2. the specific type of resource indicated by the value of the xsi:type attribute,
3. the location of the schema documents used by this description,
4. values for the three main types core metadata: identity, curation, and content,
5. a reference to another resource is made by providing that resource's IVOA identifier,
6. string values can be padded with spaces for easier readability,
7. extension metadata specific to the type of resource.

2.1. The Schema Namespace and Location

The VOResource schema namespace is "http://www.ivoa.net/xml/VOResource/v1.0". The namespace URI has been chosen to allow it to be resolved as a URL to the XML Schema document (given in Appendix A) that defines the VOResource schema. Applications may assume that the namespace URI is so resolvable.

Authors of instance documents that use the VOResource schema may choose to provide a location for VOResource XML Schema document using the xsi:schemaLocation attribute; the choice of the location value is the choice of the author. In general, the use of xsi:schemaLocation is recommended by this specification with a the namespace URI given as the location as illustrated in the example above, unless the application prefers otherwise.

xsi:schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0
                    http://www.ivoa.net/xml/VOResource/v1.0"

The VOResource schema only defines global types; it does not define any global elements (often refered to as root elements). It is the responsibility of the application to define the root element of the VOResource-employing documents it operates on. Typically, the root element is defined in a separate application-specific schema. The type of an application document's root element is not assumed to be any particular type defined in the VOResource schema (nor any of its legal extensions). In fact, it need not be of a type from the VOResource at all; rather, VOResource types may appear anywhere in the document.

Note: The IVOA Registry Interface standard, for example, includes a small schema that defines a single global element, <VOResources>, that can contain a series of <resource> child elements. The child element is defined to be of the type Resource from the VOResource schema.

Note: In the example instance document at the beginning of section 2, the root element, <resource> is not defined in any schema. Nevertheless, this document is still legal and verifiable XML. This is because the element's type is explicitly specified with the xsi:type attribute.

VOResource uses the following conventions for names of elements and types:

• all global types it defines have names that are capitalized. (This practice would extend to global elements, if they existed in the VOResource.)
• Locally defined elements begin with a lower-case character.
• For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used demarcate the start of appended word (the "camel" format).
• Names that include abbreviations, such as IdentifierURI, all letters in the abbreviation are capitalized.

Applications describe a single resource using an element of the type vr:Resource or a legal derivation of it. The content of the vr:Resource type is referred to as the core VOResource metadata, and they fall into three categories (corresponding to the sections 3.1, 3.2, and 3.3 of the RM):

• identity metadata: the <title>, <shortName>, and <identifier> elements;
• curation metadata: the contents of the <curation> element;
• general content metadata: the contents of the <content> element.

Many of the elements in VOResource that are meant to have string or URI values are defined as being of the type vr:PaddedString and vr:PaddedURI, respectively:

<xs:simpleType name="PaddedString">
  <xs:restriction base="xs:string">
    <xs:whiteSpace value="collapse"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="PaddedURI">
  <xs:restriction base="xs:anyURI">
    <xs:whiteSpace value="collapse"/>
  </xs:restriction>
</xs:simpleType>

All VOResource elements and attributes that contain dates must be interpreted as UTC dates and must be encoded in compliance with ISO8601 standard Date and Time Format [ISO8601]. This is enforced by the use of the vr:UTCDateTime:

<xs:simpleType name="UTCDateTime">
   <xs:union memberTypes="xs:date vr:UTCDateTimeZ"/>
</xs:simpleType>

<xs:simpleType name="UTCDateTimeZ">
   <xs:restriction base="xs:dateTime">
      <xs:pattern value=".*Z"/>
   </xs:restriction>
</xs:simpleType>

Copied from the OAI Protocol for Metadata Harvesting schema [OAI], this definition allows a date to have a precision of either a day (as in the xsd:date type) or the second. The latter format is forced to end with a "Z" to be compliant with the ISO8601 time zone specification.

All VOResource types and elements have an associated semantic meaning which is given in the first <xsd:documentation> node within the type or element's definition in the schema. The meaning associated with a type is generic, indicating the kind of information the type provides. The semantics that are delivered by a VOResource instance document, however, are those associated with VOResource elements. The meaning of a VOResource element can be thought of as having two parts: the generic meaning of the set of information it contains as defined by its type, and a specific meaning describing the context in which that information applies. Because all VOResource elements are locally defined element (in the XML Schema sense), they do not have an absolute meaning, but rather have a meaning tied to the thing being described by that element as represented by the enclosing type.

Additional semantics are transmitted through the use of derived types using the xsi:type attribute. In the sample instance document above, the use of xsi:type="Organisation" means that the resource being described is specifically an organisation as defined by the vr:Organisation type. This type provides additional metadata that are not part of the core resource metadata; however, in general, a derived type need not alter the content model of its base type. This allows derived types to add more specific meaning with out adding any additional metadata. The semantics associated with the use of xsi:type is described further in the next section.

A schema made up only of global type definitions provides great flexibility for extension. Any global type defined in the VOResource schema may be used as the base of a derived type defined in another schema. The schema containing the derived types must declare its own namespace URI or default to the null namespace; it must not adopt the VOResource namespace URI. The application must then define what schemas, identified by their namespace URIs, are supported and/or required.

A VOResource extension is an XML Schema document whose primary purpose is to define new types derived from those defined in the VOResource schema. It is recommended that VOResource extensions follow the definition styles used by the core VOResource. In particular:

• Provide semantic definitions of all types and elements within the first <xsd:documentation> element inside the type or element definition. Subsequent <xsd:documentation> elements may provide additional comments or discussion.

• Avoid the use of xsd:choice elements. VOResource does not use the choice structure because it does not map readily into any object-oriented software language structure. Choices are handled instead as multiple derived types that can be inserted in place of a parent type.

• Avoid the use of substitution groups. VOResource prefers instead the use of xsi:type which are functionally equivalent to substitution groups in terms of structure; however, xsi:type serves as an obvious flag in the instance document that a substitution has been made.

• Choose semantically meaningful names for derived types. When the derived type appears in the pattern <elname xsi:type="derivedType">, choose a derivedType name such that the sentence, "a derivedType is a kind of elname" makes natural and obvious sense. For example, "an Organisation is a kind of resource."

• Follow the VOResource naming conventions.

There are two types of derivation that are particularly important to the VOResource data model: derivation of the vr:Resource type, used to define specific types of resources, and the derivation of service metadata elements.

When a resource is described with an element explicitly of the type vr:Resource, it is being described in the most generic sense. The metadata presented in this type, including both free text values and controlled vocabulary, can give some sense of what type of resource is being described and what it might be used for. However, the most useful descriptions of resources will not explicitly use the vr:Resource type; rather, they will use types that are derived from vr:Resource.

Defining derived vr:Resource types accomplishes two things:

1. it sharpens the semantic meaning of the resource description by indicating what specific type of resource it is, and
2. it may allow additional metadata not part of the core but specific to the that type of resource.

The VOResource schema defines two types derived from vr:Resource: vr:Organisation and vr:Service. The vr:Organisation adds metadata describing the astronomical facilities such as telescopes that are associated with the organisation it describes. The vr:Service type adds a description of the service's interface and its specific capabilities. Specific kinds of services, particularly those defined by an IVOA standard, should be derived from vr:Service.

Note: It is recommended that the IVOA standards document that defines an IVOA standard service should include the definition of a VOResource extension schema that is used to describe implementations of the service in a registry. This schema would include a type that derives from vr:Service and may also include extensions of vr:Interface and/or vr:Capability (see sections 2.3.2 and 3.2.2).

It is intended that the most common extensions to the VOResource schema will be to define new derived vr:Resource types. Derivation of vr:Resource should be done by extension (i.e. using <xsd:extension>) rather than restriction. It is not required that the derived type change the content model from that of the vr:Resource base type; in this case, the purpose of the derivation is only to sharpen the semantic meaning of the resource description.

As described in section 2.2, it is intended that derived vr:Resource types be invoked in instance documents using the xsi:type attribute (as illustrated in the sample document above). This method illustrates a polymorphism for resource metadata in that any place where an element of type vr:Resource is expected, the derived type may be inserted. The use of xsi:type illustrates both what specific type is being inserted in as well as what it is being inserted in for. That is, as in our example, the resource being described is an organisation.

The other method of for polymorphism provided by XML Schema [Schema] is substitution groups. Invoking derived vr:Resource types via elements in a substitution group is discouraged because it is less obvious from looking at the instance document that a substitution is being made.

Note: It is intended that a set of common generic interface types would be defined in a separate VOResource extension schema. At the time of this writing, this schema is called VODataService. It defines interfaces for describing a SOAP Web Service, tradition HTTP GET and POST services, and GLU services. More specific interfaces, particularly those associated with standard IVOA services (like a Registry Service) would derive its specific interface describe from one of the common type as appropriate.

The <vr:interface> element is intended to describe how the service is called. A derived vr:Interface type must indicate in the documentation how the <vr:accessURL> should be interpreted and used. The derived type may also include other added metadata describing how to use the service (e.g., a description of the input arguments).

The VOResource schema defines another type, called vr:Capability intended for use in the derived vr:Interface types. It is intended to describe the behavior of the service and can include limitations of the service.

Note: The Simple Image Access Protocol [SIA] is an example of a standard service that defines capability metadata. These include "maxRecords" that list the maximum number of records the SIA implementation can return at a time, and "MaxImageSize" gives the maximum image size that the service can return.

Because capability metadata is not included in the base vr:Service resource type, one does not use xsi:type to insert a derived vr:Capability type into the derived vr:Service type. Instead one simply uses the derived vr:Capability type as the type of an element added to the derived vr:Service type's content model.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
            xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
            xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"
            targetNamespace="http://www.ivoa.net/xml/SIA/v1.0"
            elementFormDefault="qualified" attributeFormDefault="unqualified"
            version="1.0">

   <xs:import namespace="http://www.ivoa.net/xml/VOResource/v0.10"/>

   <xs:complexType name="SimpleImageAccess">
      <xs:annotation>
         <xs:documentation>
            A description of a particular implementation of the
            standard Simple Image Access Protocol.
         </xs:documentation>
      </xs:annotation>

      <xs:complexContent>
         <xs:extension base="vr:Service">
            <xs:sequence>

               <xs:element name="capability" type="sia:SIACapability">
                  <xs:annotation>
                     <xs:documentation>
                        a description of the behavior and limitations
                        of the SIA implementation.  
                     </xs:documentation>
                  </xs:annotation>
               </xs:element>

            </xs:sequence>
         </xs:extension>
      </xs:complexContent>

   </xs:complexType>

   <xs:complexType name="SIACapability">
      <xs:annotation>
         <xs:documentation>
            The capabilities of an SIA implementation.  
         </xs:documentation>
      </xs:annotation>

      <xs:complexContent>
         <xs:extension base="vr:Capability">

            <xs:sequence>

               <xs:element name="maxRecords" type="xs:int">
                  <xs:annotation>
                     <xs:documentation>
                        The largest number of records that the Image Query web
                        method will return. 
                     </xs:documentation>
                  </xs:annotation>
               </xs:element>

               <!-- other capability metadata -->
            </xs:sequence>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

</xs:schema>

<resource xsi:type="sia:SimpleImageAccess"
  xmlns="http://www.ivoa.net/xml/VOResource/v1.0"
  xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
  xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    <!-- the core VOResource metadata -->

    <vr:interface xsi:type="...">
      <!-- interface description -->
    </vr:interface>

    <sia:capability xmlns="http://www.ivoa.net/xml/SIA/v1.0">
       <maxRecords>5000</maxRecords>
       <!-- other capability metadata -->
    </sia:capability>

</resource>

This section enumerates the types and elements defined in the VOResource schema and describes their meaning in terms of the RM.

A resource, as defined by the RM, is any entity or component of a VO application that is describable and identifiable by a IVOA Identifier. A resource is described using VOResource by an element of the type vr:Resource or one of its legal extensions. The schema definition (below) includes elements that encode the identity, curation, and general content metadata for a resource (see sections 3.1 thru 3.3 of the RM). The RM states that certain metadata are required in a minimally compliant resource description; this requirement is enforced by the VOResource schema definition.

<xs:complexType name="Resource">
   <xs:sequence>

      <xs:element name="title" type="vr:PaddedString"/>
      <xs:element name="shortName" type="vr:ShortName" minOccurs="0"/>
      <xs:element name="identifier" type="vr:IdentifierURI"/>
      <xs:element name="curation" type="vr:Curation"/>
      <xs:element name="content" type="vr:Content">

   </xs:sequence>

   <xs:attribute name="created" type="xs:date"/>
   <xs:attribute name="updated" type="xs:date"/>
   <xs:attribute name="status" default="active"/>
      <xs:simpleType>
         <xs:restriction base="xs:string">
            <xs:enumeration value="active"/>
            <xs:enumeration value="inactive"/>
            <xs:enumeration value="deleted"/>
         </xs:restriction>
      </xs:simpleType>
   </xs:attribute>
</xs:complexType>

The vr:Resource attributes represent a special class of metadata: they describe the resource metadata description contained within the vr:Resource itself as opposed to the resource being described. Their meaning are as follows:

The following sections define the elements that encode the specific metadata from the RM. In all cases, the semantic meaning of an element is defined by the RM metadatum it corresponds to (labeled "RM Name" below). All rules and advice given in the "Comments" portions in the RM definition apply. Any textual differences in the semantic definitions given below from those given in the RM are intended only for clarification for the XML encoding context.

The identity metadata described in the RM (section 3.1) are represented as top-level children of the vr:Resource type.

Two special types, vr:ShortName and vr:identifierURI are defined to support identity metadata. The vr:ShortName definition enforces the 16-character limit on shortNames.

<xs:simpleType name="ShortName">
  <xs:restriction base="xs:string">
     <xs:maxLength value="16"/>
  </xs:restriction>
</xs:simpleType>

The vr:IdentifierURI enforces the URI syntax for IVOA Identifiers as defined by the IVOA Identifier standard [ID].

<xs:simpleType name="IdentifierURI">
  <xs:restriction base="xs:anyURI">
    <xs:pattern value="ivo://[\w\d][\w\d\-_\.!~\*'\(\)\+=]{2,}
(/[\w\d\-_\.!~\*'\(\)\+=]+(/[\w\d\-_\.!~\*'\(\)\+=]+)*)?"/>
  </xs:restriction>
</xs:simpleType>

Two additional types which are not used within the vr:Resource type but are available to support the two components of an IVOA Identifier [ID]: vr:AuthorityID and vr:ResourceKey.

<xs:simpleType name="AuthorityID">
  <xs:restriction base="xs:string">
    <xs:pattern value="[\w\d][\w\d\-_\.!~\*'\(\)\+=]{2,}"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="ResourceKey">
  <xs:restriction base="xs:string">
    <xs:pattern value="[\w\d\-_\.!~\*'\(\)\+=]+(/[\w\d\-_\.!~\*'\(\)\+=]+)*"/>
  </xs:restriction>
</xs:simpleType>

The curation metadata described in the RM (section 3.2) are bundled together into the vr:Resource child element, <vr:curation>. Its content is defined by the vr:Curation complex type.

<xs:complexType name="Curation">
  <xs:sequence>

    <xs:element name="publisher" type="vr:ResourceName"/>
    <xs:element name="creator" type="vr:Creator"
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="contributor" type="vr:ResourceName"
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="date" type="vr:Date" 
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="version" type="vr:PaddedString" minOccurs="0"/>
    <xs:element name="contact" type="vr:Contact"/>

  </xs:sequence>
</xs:complexType>

vr:Curation Metadata Elements
Element	Definition
publisher	RM Name: Publisher, PublisherID (see type definition below) Value type: string with optional ID attribute: vr:ResourceName Semantic Meaning: Entity (e.g. person or organisation) responsible for making the resource available Occurances: required Comments: The PublisherID is encoded as an optional attribute
creator	RM Name: Creator, Creator.Logo (see type definition below) Value type: composite: vr:Creator Semantic Meaning: The entity (e.g. person or organisation) primarily responsible for creating the content or constitution of the resource. Occurances: optional; multiple occurances allowed Comments: If <vr:creator> element appears, it must contain at least a name. If multiple creator elements appear, but only one logo is provided (see type definition below), applications may assume that the one logo applies to all creators.
contributor	RM Name: Contributor Value type: string with optional ID attribute: vr:ResourceName Semantic Meaning: Entity responsible for contributions to the content of the resource. Occurances: optional; multiple occurances allowed
date	RM Name: Date Value type: UTC time stamp with optional role attribute: vr:Date Semantic Meaning: Date associated with an event in the life cycle of the resource. Occurances: optional; multiple occurances allowed
version	RM Name: Version Value type: string: vr:PaddedString Semantic Meaning: Label associated with creation or availablilty of a version of a resource. Occurances: optional
contact	RM Name: Contact, Contact.Name, Contact.Email Value type: composite: vr:Contact Semantic Meaning: Information that can be used for contacting someone with regard to this resource. Occurances: required; multiple occurances allowed

Several of the curation elements (most importantly, <vr:publisher>) make use of the vr:ResourceName type. This type is provides a means of refering to another resource both by name and by its IVOA identifier. Not all resources refered to using this type will necessarily be registered and, therefore, will have an identifier; thus, the identifier (which is encoded as an attribute) is optional.

<xs:complexType name="ResourceName">
  <xs:simpleContent>
    <xs:extension base="vr:PaddedString"> 
      <xs:attribute name="ivo-id" type="vr:IdentifierURI"/>
    </xs:extension>       
  </xs:simpleContent>
</xs:complexType>   

The <vr:creator> element is defined by the vr:Creator complex type which bundles together the RM metadata Creator and Creator.Logo.

<xs:complexType name="Creator">
   <xs:sequence>
     <xs:element name="name" type="vr:ResourceName"/>
     <xs:element name="logo" type="xs:anyURI" minOccurs="0"/>
   </xs:sequence>
</xs:complexType>

The <vr:Date> element's type, vr:Date, is an extension of the UTCDateTime type that adds an optional attribute called role.

<xs:complexType name="Date">
   <xs:simpleContent>
      <xs:extension base="vr:UTCDateTime">
        <xs:attribute name="role" type="xs:string" default="representative"/>
      </xs:extension>
   </xs:simpleContent>
</xs:complexType>

It is important to note that the <date> element describes the resource itself, not the resource record that describes it. Dates describing the resource record are covered by vr:Resource attributes created and updated

The <vr:contact> element is defined by the vr:Contact type which bundles together several component pieces of information, including the RM metadata Contact.Name and Contact.Email.

<xs:complexType name="Contact">
  <xs:sequence>

     <xs:element name="name" type="vr:ResourceName"/>
     <xs:element name="address" type="vr:PaddedString" minOccurs="0"/>
     <xs:element name="email" type="vr:PaddedString" minOccurs="0"/>
     <xs:element name="telephone" type="vr:PaddedString" minOccurs="0"/>

   </xs:sequence>
</xs:complexType>

The general content metadata described in the RM (section 3.3) are bundled together into the vr:Resource child element, <vr:content>. Its content is defined by the vr:Content complex type.

<xs:complexType name="Content">
  <xs:sequence>

    <xs:element name="subject" type="vr:PaddedString"
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="description" type="vr:PaddedString"/>
    <xs:element name="source" type="vr:Source" minOccurs="0"/>
    <xs:element name="referenceURL" type="vr:PaddedURI"/>
    <xs:element name="type" type="vr:Type" minOccurs="0"/>
    <xs:element name="contentLevel" type="vr:ContentLevel" 
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="relationship" type="vr:Relationship" 
                minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>
</xs:complexType>

vr:Content Metadata Elements
Element	Definition
subject	RM Name: Subject Value type: string: vr:PaddedString Semantic Meaning: a topic, object type, or other descriptive keywords about the resource. Occurances: required; multiple occurances allowed
description	RM Name: Description Value type: string: vr:PaddedString Semantic Meaning: An account of the nature of the resource. Occurances: required Comments: The description may include but is not limited to an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
source	RM Name: Source Value type: a formatted reference (e.g. ADS Bibcode): vr:Source Semantic Meaning: a bibliographic reference from which the present resource is derived or extracted. Occurances: optional
referenceURL	RM Name: ReferenceURL Value type: URL: vr:PaddedURI Semantic Meaning: URL pointing to a human-readable document describing the resource. Occurances: required
type	RM Name: Type Value type: string with controlled vocabulary: vr:Type Semantic Meaning: Nature or genre of the content of the resource Occurances: optional; multiple occurances allowed Allowed Values: Other resource that does not fall into any of the category names currently defined. Archive Collection of pointed observations Bibliography Collection of bibliographic reference, abstracts, and publications Catalog Collection of derived data, primarily in tabular form Journal Collection of scholarly publications under common editorial policy Library Collection of published materials (journals, books, etc.) Simulation Theoretical simulation or model Survey Collection of observations covering substantial and contiguous areas of the sky Transformation A service that transforms data Education Collection of materials appropriate for educational use, such as teaching resources, curricula, etc. Outreach Collection of materials appropriate for public outreach, such as press releases and photo galleries EPOResource Collection of materials that may be suitable for EPO products but which are not in final product form, as in Type Outreach or Type Education. EPOResource would apply, e.g., to archives with easily accessed preview images or to surveys with easy-to-use images. Animation Animation clips of astronomical phenomena Artwork Artists' renderings of astronomical phenomena or objects Background Background information on astronomical phenomena or objects BasicData Compilations of basic astronomical facts about objects, such as approximate distance or membership in constellation Historical Historical information about astronomical objects Photographic Publication-quality photographs of astronomical objects Press Press releases about astronomical objects Organisation An organization that is a publisher or curator of other resources Project A project that is a publisher or curator of other resources Registry a query service for which the response is a structured description of resources
contentLevel	RM Name: ContentLevel Value type: string with controlled vocabulary: vr:ContentLevel Semantic Meaning: Description of the content level or intended audience Occurances: optional; multiple occurances allowed Allowed Values: General Resource provides information appropriate for all users. Elementary Education Resource provides information appropriate for use in elementary education (e.g. approximate ages 6-11). Middle School Education Resource provides information appropriate for use in middle school education (e.g. approximate ages 11-14). Secondary Education Resource provides information appropriate for use in elementary education (e.g. approximate ages 14-18). Community College Resource provides information appropriate for use in community/junior college or early university education. University Resource provides information appropriate for use in university education. Research Resource provides information appropriate for supporting scientific research. Amateur Resource provides information of interest to amateur astronomers. Informal Education Resource provides information appropriate for education at museums, planetariums, and other centers of informal learning.
relationship	RM Name: Relationship, RelationshipID Value type: composite: vr:Relationship Semantic Meaning: a description of a relationship to another resource Occurances: optional; multiple occurances allowed

The <vr:source> element's type, vr:Source, is an extension of the vr:PaddedString type that adds an optional attribute called format.

<xs:complexType name="Source">
   <xs:simpleContent>
      <xs:extension base="vr:PaddedString">
        <xs:attribute name="format" type="xs:string"/>
      </xs:extension>
   </xs:simpleContent>
</xs:complexType>

The format indicates the syntactic format of the value of the <source> element. The possible values for this attribute are not controlled; however, applications should recognize a value equal to bibcode as referring to the standard astronomical bibcode format [Bibcode].

The <relationship> is defined by the vr:Relationship complex type which bundles together the RM metadata Relationship and RelationshipID.

<xs:complexType name="Relationship">
   <xs:sequence>
      <xs:element name="relationshipType" type="vr:RelationshipType"/>
      <xs:element name="relatedResource" type="vr:ResourceName" 
                  minOccurs="1" maxOccurs="unbounded"/>
   </xs:sequence>
</xs:complexType>

The VOResource schema defines two extensions of the base vr:Resource type for describing two specific types of resources: vr:Organisation and vr:Service. In addition to providing more refined semantic meaning over vr:Resource, they add additional metadata for the describing the resource which don't necessarily apply in the generic case.

The Organisation resource type is used to describe an organisation in the sense defined by the RM:

An organisation is a specific type of resource that brings people together to pursue participation in VO applications. Organisations can be hierarchical and range greatly in size and scope. At a high level, an organisation could be a university, observatory, or government agency. At a finer level, it could be a specific scientific project space mission, or individual researcher.

The Organisation type extends the Resource type by adding two additional elements to the core set of metadata, <vr:facility> and <vr:instrument>:

<xs:complexType name="Organisation">
   <xs:complexContent>
      <xs:extension base="vr:Resource">
         <xs:sequence>

            <xs:element name="facility" type="vr:ResourceName"
                        minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="instrument" type="vr:ResourceName"
                        minOccurs="0" maxOccurs="unbounded"/>

         </xs:sequence>
      </xs:extension>
   </xs:complexContent>
</xs:complexType>

The main role of an organisation in the VO (that is, the main reason for describing organisations in a registery) is as a provider or publishier of other resources. In particular, an organisation description in a registry declares the association of an IVOA identifier [ID] with the organisation. The organisation can then be referred to in other resource descriptions. For example, an organisation identifier will appear as the publisher identifier of service resource (as illustrated in our example from section 2).

The Service resource type is used to describe a service--a resource that actually does something--in the sense defined by the RM:

A service is any VO resource that can be invoked by the user to perform some action on their behalf.

The Service type extends the Resource type by adding the element <vr:interface> which describes how the service is invoked.

<xs:complexType name="Service">
   <xs:complexContent>
      <xs:extension base="vr:Resource">
         <xs:sequence>
            <xs:element name="interface" type="vr:Interface"
                           minOccurs="1" maxOccurs="unbounded"/>
         </xs:sequence>
      </xs:extension>
   </xs:complexContent>
</xs:complexType>

<xs:complexType name="Interface" abstract="true">
   <xs:sequence>
      <xs:element name="accessURL" type="vr:AccessURL"/>
   </xs:sequence>
</xs:complexType>

The vr:Interface type is defined as abstract, so as described in section 2.3.2, the <vr:interface> element must not be used as part of a vr:Service description unless it includes an xsi:type attribute that refers to a type derived from vr:Interface. The VOResource schema defines one derived vr:Interface type which may be used in this way called vr:WebBrowser.

As mentioned in the table above, exactly how a client uses the value of the <accessURL> element depends on the specific type derived from vr:Interface. Extension schemas that define non-abstract types derived from vr:Interface MUST provide documentation that explains the exact use of the <accessURL>; this documentation should follow the documention conventions described in section 2.2.

As an additional aid to software agents that will attempt to interpret its URL, the vr:AccessURL includes an optional element, use (pronounced and interpreted as in the noun form of the word use) which takes a controlled vocabulary:

<xs:complexType name="AccessURL">
  <xs:simpleContent>
    <xs:extension base="xs:anyURI">
      <xs:attribute name="use">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="full"/>
            <xs:enumeration value="base"/>
            <xs:enumeration value="post"/>
            <xs:enumeration value="dir"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

The VOResource schema defines one type derived from vr:Interface called vr:WebBrowser. This type indicates that the service is intended to be accessed interactively by a user through a web browser. The <accessURL>, then, reprensents the URL of a web page containing one or more forms used to invoke the service.

<xs:complexType name="WebBrowser">
   <xs:complexContent>
      <xs:extension base="vr:Interface">
         <xs:sequence/>
      </xs:extension>
   </xs:complexContent>
</xs:complexType>

<xs:complexType name="Capability">
   <xs:sequence/>
   <xs:attribute name="standardID" type="vr:IdentifierURI"/>
</xs:complexType>

The general meaning of this type is a description of the behavior and limitations of a service. Typically, a VOResource extension schema for describing an instance of a standard service would define a type derived from vr:Capability which adds child elements that are specific to that type of service.

References

[RFC 2119]

Bradner, S. 1997. Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, http://www.ietf.org/rfc/rfc2119.txt

[RM]

Hanisch, Robert (ed.) 2004. Resource Metadata for the Virtual Observatory, Version 1.01, IVOA Recommendation, http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm

[xml]

Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M., Maler, Eve, Yergeau, Francois (editors) 2004, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004, http://www.w3.org/TR/REC-xml

[schema]

Fallside, David C., Walmsley, Priscilla (editors) 2004, XML Schema Part 0: Primer Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/xmlschema-0/

[ISO8601]

Wolf, Misha and Wicksteed, Charles 1997, Date and Time Format, http://www.w3.org/TR/NOTE-datetime.

[OAI]

Lagoze, Carl, Van de Sompel, Herbert, Nelson, Michael, and Warner, Simeon 2004, The Open Archives Initiative Protocol for Metadata Harvesting, http://www.openarchives.org/OAI/openarchivesprotocol.html.

[SIA]

Tody, Doug and Plante, Ray 1997, Simple Image Access Specification Version 1.0, http://www.ivoa.net/Documents/WD/SIA/sia-20040524.html.

[ID]

Plante, R., Linde, T., Williams, R., Noddle, K. 2005, IVOA Identifiers v1.1, http://www.ivoa.net/Documents/REC/Identifiers/Identifiers-200505XX.html.

[Bibcode]

Schmitz, M., Helou, G., Dubois, P., LaGue, C., Madore, B., Corwin, H. G., & Lesteven, S. NED and SIMBAD Convention for Bibliographic Reference Coding, http://cdsweb.u-strasbg.fr/simbad/refcode/refcode-paper.html.