International Virtual Observatory Alliance

Difference: VOSpace11Spec (5 vs. 6)

Revision 62007-08-13 - MatthewGraham

META TOPICPARENT	name="VOSpaceHome"

VOSpace home page

Discussion of the VOSpace 1.1 specification

This is a discussion page for the VOSpace-1.1 service specification.

Version 1.1 aims to extend the VOSpace-1.0 specification to include links and containers. The proposed mechanism is that we introduce two new node types:

LinkNode - this is like a Node but also has a URI to where the link is pointing
ContainerNode - this cannot hold any data (no bytes) but can have children nodes (of any type) and views for container level formatting (aggregate zip/gzip).

At the May 2007 interop, we identified the following items as requiring resolution for VOSpace 1.1:

Container level metadata - how to distinguish those that relate to the contents of the container through inheritance and those to the container itself
Generated names - vos://null does not work for containers so use ".auto" or "/" as an alternative
Typing of protocol and view parameters - these are currently designated as "string" but normal parameters are "URI"
ACL - although this forms part of a wider SSO context, should VOSpace have some notions of ACL control
Find - a equivalent to the Unix command is desired

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

+1 if you agree
0 if you think the proposal is useful but needs more work
-1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Added:

>
>

Logical storage units

A request has from our friends at SDSC to include references to the actual storage units that data is being deposited on. The use case is data replication so, for example, I want to move/copy a data object from a slow tape archive to an ultrafast disk but both hardware units are within the same VOSpace or I want to retrieve a data object from the ultrafast disk copy and not the slow tape one.

I think that we can incorporate this easily into our existing data model. We will refer to hardware units as logical storage units with the implication that they are identified via a logical identifier (URI) that is set by the particular VOSpace implementation. To get the list of available storage units from a VOSpace, we will need a method: getLogicalStorageUnits() which will return a list of URIs. These URIs may be resolvable to a description of the storage unit.

The logical storage unit identifier will be an optional argument in the entity so that as part of the data transfer negotiation, the user can specify a list of storage units that they want the data transferred to/from. The identifier will also be an optional argument in the entity so that specific hardware can be targetted in moving and copying data. (MatthewGraham - 13 Aug 2007)

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r14 < r13 < r12 < r11 | More topic actions...