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.