VOResource xs vr An XML Schema describing a resource to be used in the Virtual Observatory Project. Please see http://www.ivoa.net/documents/latest/VOResource.html for further information on the standard governing this schema. A timestamp that is compliant with ISO8601 and fixes the timezone indicator, if present, to "Z" (UTC). VOResource writers should always include the timezone marker. VOResource readers must interpret timestamps without a timezone marker as UTC. A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime). Where only a date is given, it is to be interpreted as the span of the day on the UTC timezone if such distinctions are relevant. Any entity or component of a VO application that is describable and identifiable by an IVOA Identifier. A numeric grade describing the quality of the resource description, 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. See vr:Validation for an explanation of the allowed levels. Note that when this resource is a Service, this grade applies to the core set of metadata. Capability and interface metadata, as well as the compliance of the service with the interface standard, is rated by validationLevel tag in the capability element (see the vr:Service complex type). Title the full name given to the resource A short name or abbreviation given to the resource. This name will be used where brief annotations for the resource name are required. Applications may use to refer to this resource in a compact display. One word or a few letters is recommended. No more than sixteen characters are allowed. Identifier Unambiguous reference to the resource conforming to the IVOA standard for identifiers A reference to this resource in a non-IVOA identifier scheme, e.g., DOI or bibcode. Always use the an URI scheme here, e.g., doi:10.1016/j.epsl.2011.11.037. For bibcodes, use a form like bibcode:2008ivoa.spec.0222P. Information regarding the general curation of the resource Information regarding the general content of the resource The UTC date and time this resource metadata description was created. This timestamp must not be in the future. This time is not required to be accurate; it should be at least accurate to the day. Any non-significant time fields should be set to zero. The UTC date this resource metadata description was last updated. This timestamp must not be in the future. This time is not required to be accurate; it should be at least accurate to the day. Any non-significant time fields should be set to zero. a tag indicating whether this resource is believed to be still actively maintained. resource is believed to be currently maintained, and its description is up to date (default). resource is apparently not being maintained at the present. resource publisher has explicitly deleted the resource. The VOResource XML schema version against which this instance was written. Implementors should set this to the value of the version attribute of their schema's root (xs:schema) element. Clients may assume version 1.0 if this attribute is missing. The allowed values for describing the resource descriptions and interfaces. See the RM (v1.1, section 4) for more guidance on the use of these values. The resource has a description that is stored in a registry. This level does not imply a compliant description. In addition to meeting the level 0 definition, the resource description conforms syntactically to this standard and to the encoding scheme used. In addition to meeting the level 1 definition, the resource description refers to an existing resource that has demonstrated to be functionally compliant. When the resource is a service, it is considered to exist and functionally compliant if use of the service accessURL responds without error when used as intended by the resource. If the service is a standard one, it must also demonstrate the response is syntactically compliant with the service standard in order to be considered functionally compliant. If the resource is not a service, then the ReferenceURL must be shown to return a document without error. In addition to meeting the level 2 definition, the resource description has been inspected by a human and judged to comply semantically to this standard as well as meeting any additional minimum quality criteria (e.g., providing values for important but non-required metadata) set by the human inspector. In addition to meeting the level 3 definition, the resource description meets additional quality criteria set by the human inspector and is therefore considered an excellent description of the resource. Consequently, the resource is expected to operate well as part of a VO application or research study. a validation stamp combining a validation level and the ID of the validator. The IVOA ID of the registry or organisation that assigned the validation level. A reference to a registry record. This type should only be used if what is referenced must actually be a true Registry record; vr:IdentifierURI does not allow query or fragment parts and is hence not suitable for everything defined by IVOA Identifiers, in particular not standard keys (which are used for versions of standards, for instance) or dataset identifiers. When something does not need to be locked down to a reference to a single registry record, xs:anyURI should be used. A short name or abbreviation given to something. This name will be used where brief annotations for the resource name are required. Applications may use to refer to this resource in a compact display. One word or a few letters is recommended. No more than sixteen characters are allowed. Information regarding the general curation of a resource Publisher Entity (e.g. person or organisation) responsible for making the resource available Creator The entity/ies (e.g. person(s) or organisation) primarily responsible for creating the content or constitution of the resource. This is the equivalent of the author of a publication. Contributor Entity responsible for contributions to the content of the resource Date Date associated with an event in the life cycle of the resource. This will typically be associated with the creation or availability (i.e., most recent release or version) of the resource. Use the role attribute to clarify. Label associated with creation or availablilty of a version of a resource. Information that can be used for contacting someone with regard to this resource. The name of a potentially registered resource. That is, the entity referred to may have an associated identifier. The IVOA identifier for the resource referred to. Information allowing establishing contact, e.g., for purposes of support. the name or title of the contact person. This can be a person's name, e.g. “John P. Jones” or a group, “Archive Support Team”. the contact mailing address All components of the mailing address are given in one string, e.g. “3700 San Martin Drive, Baltimore, MD 21218 USA”. the contact email address the contact telephone number Complete international dialing codes should be given, e.g. “+1-410-338-1234”. A reference to this entitiy in a non-IVOA identifier scheme, e.g., orcid. Always use a URI form including a scheme here. An IVOA identifier for the contact (typically when it is an organization). The entity (e.g. person or organisation) primarily responsible for creating something the name or title of the creating person or organisation Users of the creation should use this name in subsequent credits and acknowledgements. This should be exactly one name, preferably last name first (as in "van der Waals, Johannes Diderik"). URL pointing to a graphical logo, which may be used to help identify the information source A logo needs only be provided for the first occurrence. When multiple logos are supplied via multiple creator elements, the application is free to choose which to use. A reference to this entitiy in a non-IVOA identifier scheme, e.g., orcid. Always use a URI form including a scheme here. An IVOA identifier for the creator (typically when it is an organization). A string indicating what the date refers to. The value of role should be taken from the vocabulary maintained at http://www.ivoa.net/rdf/voresource/date_role. This includes the traditional and deprecated strings “creation”, indicating the date that the resource itself was created, and “update”, indicating when the resource was updated last, and the default value, “representative”, meaning the date is a rough representation of the time coverage of the resource. The preferred terms from that vocabulary are the DataCite Metadata terms. It is expected that the vocabulary will be kept synchronous with the corresponding list of terms in the DataCite Metadata schema. Note that this date refers to the resource; dates describing the metadata description of the resource are handled by the “created” and “updated” attributes of the Resource element. Information regarding the general content of a resource Subject a topic, object type, or other descriptive keywords about the resource. Terms for Subject should be drawn from the Unified Astronomy Thesaurus (http://astrothesaurus.org). Description An account of the nature of the resource 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. Note that description is xs:string-typed, which means that whitespace is considered significant. Clients should render empty lines as paragraph boundaries and ideally refrain from reflowing material that looks formatted (i.e., is broken to about 80-character lines). Source a bibliographic reference from which the present resource is derived or extracted. This is intended to point to an article in the published literature. An ADS Bibcode is recommended as a value when available. URL pointing to a human-readable document describing this resource. Type Nature or genre of the content of the resource. Values for type should be taken from the controlled vocabulary http://www.ivoa.net/rdf/voresource/content_type Subject Subject.ContentLevel Description of the content level or intended audience. Values for contentLevel should be taken from the controlled vocabulary http://www.ivoa.net/rdf/voresource/content_level. a description of a relationship to another resource. The reference format. Recognized values include “bibcode”, referring to a standard astronomical bibcode (http://cdsweb.u-strasbg.fr/simbad/refcode.html). A description of the relationship between one resource and one or more other resources. the named type of relationship The value of relationshipType should be taken from the vocabulary at http://www.ivoa.net/rdf/voresource/relationship_type. the name of resource that this resource is related to. A named group of one or more persons brought together to pursue participation in VO applications. According to the Resource Metadata Recommendation, organisations “can be hierarchical and range 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, mission, or individual researcher.” The main purpose of an organisation as a registered resource is to serve as a publisher of other resources. Subject the observatory or facility used to collect the data contained or managed by this resource. Subject Subject.Instrument the Instrument used to collect the data contain or managed by a resource. a resource that can be invoked by a client to perform some action on its behalf. Rights Information about rights held in and over the resource. Mainly for compatibility with DataCite, this element is repeatable. Resource record authors are advised that within the Virtual Observatory clients will typically only display and/or use the rights element occurring first and ignore later elements. a description of a general capability of the service and how to use it. This describes a general function of the service, usually in terms of a standard service protocol (e.g. SIA), but not necessarily so. A service can have many capabilities associated with it, each reflecting different aspects of the functionality it provides. A statement of usage conditions. This will typically include a license, which should be given as a full string (e.g., Creative Commons Attribution 3.0 International). Further free-text information, e.g., on how to attribute or on embargo periods is allowed. A URI identifier for a license Where formal licenses are available, this URI can reference the full license text. The IVOA may define standard URIs for a set of recommended licenses, in which case these should be used here. a description of what the service does (in terms of context-specific behavior), and how to use it (in terms of an interface) 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. See vr:ValidationLevel for an explanation of the allowed levels. A human-readable description of what this capability provides as part of the over-all service Use of this optional element is especially encouraged when this capability is non-standard and is one of several capabilities listed. a description of how to call the service to access this capability Since the Interface type is abstract, one must describe the interface using a subclass of Interface, denoting it via xsi:type. Multiple occurences can describe different interfaces to the logically same capability, i.e. data or functionality. That is, the inputs accepted and the output provides should be logically the same. For example, a WebBrowser interface given in addition to a WebService interface would simply provide an interactive, human-targeted interface to the underlying WebService interface. A URI identifier for a standard service. This provides a unique way to refer to a service specification standard, such as a Simple Image Access service. The use of an IVOA identifier here implies that a VOResource description of the standard is registered and accessible. A description of a service interface. Since this type is abstract, one must use an Interface subclass to describe an actual interface. Additional interface subtypes (beyond WebService and WebBrowser) are defined in the VODataService schema. The URL (or base URL) that a client uses to access the service. How this URL is to be interpreted and used depends on the specific Interface subclass Although the schema allows multiple occurrences of accessURL, multiple accessURLs are deprecated. Each interface should have exactly one access URL. Where an interface has several mirrors, the accessURL should reflect the “primary” (fastest, best-connected, best-maintained) site, the one that non-sophisticated clients will go to. Additional accessURLs should be put into mirrorURLs. Advanced clients can retrieve the mirrorURLs and empirically determine interfaces closer to their network location. A (base) URL of a mirror of this interface. As with accessURL, how this URL is to be interpreted and used depends on the specific Interface subclass This is intended exclusively for true mirrors, i.e., interfaces that are functionally identical to the original interface and that are operated by the same publisher. Other arrangements should be represented as separate services linked by mirror-of relationships. The mechanism the client must employ to authenticate to the service. Services not requiring authentication must provide at least one interface definition without a securityMethod defined. Test data for exercising the service. This contains data that can be passed to the interface to retrieve a non-empty result. This can be used by validators within test suites. Exactly how agents should use the data contained in the testQueryString depends on the concrete interface class. For interfaces employing the HTTP GET method, however, this will typically be urlencoded parameters (as for the application/x-www-form-urlencoded media type). The version of a standard interface specification that this interface complies with. Most VO standards indicate the version in the standardID attribute of the capability. For these standards, the version attribute should not be used. A tag name that 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. For an interface complying with some registered standard (i.e. has a legal standardID), the role can be matched against interface roles enumerated in standard resource record. The interface descriptions in the standard record can provide default descriptions so that such details need not be repeated here. A flag indicating whether this should be interpreted as a base URL, a full URL, or a URL to a directory that will produce a listing of files. The default value assumed when one is not given depends on the context. Assume a full URL--that is, one that can be invoked directly without alteration. This usually returns a single document or file. Assume a base URL--that is, one requiring an extra portion to be appended before being invoked. Assume URL points to a directory that will return a listing of files. A URL of a mirror (i.e., a functionally identical additional service interface) to A terse, human-readable phrase indicating the function or location of this mirror, e.g., “Primary Backup” or “European Mirror”. a description of a security mechanism. This type only allows one to refer to the mechanism via a URI. Derived types would allow for more metadata. A URI identifier for a standard security mechanism. This provides a unique way to refer to a security specification standard. The use of an IVOA identifier here implies that a VOResource description of the standard is registered and accessible. A (form-based) interface intended to be accesed interactively by a user via a web browser. The accessURL represents the URL of the web form itself. A Web Service that is describable by a WSDL document. The accessURL element gives the Web Service's endpoint URL. The location of the WSDL that describes this Web Service. If not provided, the location is assumed to be the accessURL with "?wsdl" appended. Multiple occurrences should represent mirror copies of the same WSDL file.