This page was just a scratch page for editing the views section of the spec. The text from this page has been folded back into the main page on the specification pages VOSpace20070104.

---

---

Views

A View defines a data format describes the data formats and contents available for importing or exporting data to or from a VOSpace node.

The metadata for each VOSpace Node contains two lists of Views.

• accepts is a list of Views that the service can accept for importing data into the Node
• provides is a list of Views that the service can provide for exporting data from Node

The A View structure has the following members:

• View. uri : The URI for the data format eg:the View identifier
  • ivo://net.ivoa.vospace/formats/binary
  • ivo://net.ivoa.vospace/formats/votable-1.0
  • ivo://net.ivoa.vospace/formats/any – this is a reserved URI to identify unstructured data, ie. data of any format.

• View. original : if true,an optional boolean flag to indicate that the View preserves the original bit pattern of the data is preserved. This is an optional member with a default value of true if it is not specified.
• View. param : These a set of name-value pairs that can be used to specify additional arguments required to define for the View eg. JPEG compression level.

Example use cases

Simple file store

A simple VOSpace system that stores data as a binary files can just return the contents of the original file. The client supplies a View identifier when it imports the data, and the service uses this information to describe the data to other clients.

A file based system can use the special case View identifier ivo://net.ivoa.vospace/views/any in its accepts list to indicate that it will accept any data format or View for a Node.

For example :

• A client imports a file into the service, specifying a View to decribe the file contents
• The service stores the data as a binary file and keeps a record of the View
• The service can then use the View supplied by the client to describe the data to other clients

This type of service is not required to understand the data format, or to verify the file contents match the View, it treats all data as binary files.

Database store

A VOSpace system that stores data in database tables would need to be able to understand the data format of an imported file in order to parse the data and store it correctly. In order to tell the client what input data formats it can accept, the service publishes a list of specific Views in the accepts list for each Node.

On the output side, a database system would not be able to provide access to the original input file. The contents of file would have been transferred into the database table and then discarded. The system has to generate the output results from the contents of the database table. In order to support this, the service needs to be able to tell the client what Views, the data is available in.

The database system may offer access to the table contents as either VOTable or FITS files, it may also offer zip or tar.gz compressed versions of these. In which case the system needs to be able to express nested file formats such as 'zip file containing VOTable' and 'tar.zg file containing FITS'.

A service may also offer subsets of the data. For example, a workflow system may only need to look at the table headers to decide what steps are required to process the data. If the table contains a large quantity of data, then downloading the whole contents just to look at the header information is inefficient. To make this easier, a database system may offer a 'metadata only' View of the table, returning a VOTable or FITS file containing just the metadata headers and no rows.

So our example service may want to offer the following Views of a database table :

• Table contents as FITS
• Table contents as VOTable

• Table contents as zip containing FITS
• Table contents as zip containing VOTable

• Table contents as tar.gz containing FITS
• Table contents as tar.gz containing VOTable

• Table metadata as FITS
• Table metadata as VOTable

The service would publish this information as a list of Views in the provides section of the metadata for each Node.

The VOSpace specification does not mandate what Views a service must provide. The VOSpace specification is intended to provide a flexible mechanism enabling services to describe a variety of different Views of data. It is upto the service implementation to decide what Views of the data it can accept and provide.

View identifiers

Every new type of View requires a unique URI to identify the View and its content.

The rules for the View identifiers are similar to the rules for namespace URIs in XML schema. The only restriction is that it must be a vaild (unique) URI.

• An XML schema namespace identifier can be just a simple URN, e.g. urn:my-namespace
• Within the IVOA, the convention for namespace identifiers is to use a HTTP URL pointing to the namespace schema, or a resource describing it

The current VOSpace schema defines View identifiers as anyURI, but it does not restrict what the URI must contain.

• A View URI can be a simple URN, e.g. urn:my-view

This may be sufficient for testing and development on a private system, but it is not scalable for use on a public service.
For a production system, any new Views should have unique URIs that can be resolved into to a description of the View.

Ideally, these should be IVO registry URIs that point to a description registered in the IVO registry.

• e.g. ivo://my-registry/vospace/views/my-view

Using an IVO registry URI to identify Views has two main advantages

• IVO registry URIs are by their nature unique, which makes it easy to ensure that different teams do not accidentally use the same URI.
• If the IVO registry URI points to a description registered in the IVO registry, this provides a mechanism to discover what the View contains.

View descriptions

If the URI for a particular View is resolvable, i.e. an IVO registry identifier or a HTTP URL, then it should point to an XML resource that describes the View. However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalised.

A ViewDescription should describe the data format and/or content of the view..

A ViewDescription should have the following members.

• uri : the formal URI of the View
• Description : Text block explaining the data format and content of the View
• DisplayName : Display name of the View

A ViewDescription may have the following optional members.

• MimeType : the standard MIME type of the View, if applicable.