Notes from the VOSpace-1.x session at IVOA conference.

Deprecate pagination in ListNodes^?

Pagination remains unchanged.

Auto generated identifiers

The discussion looked at alternatives for the current vos://null used in VOSpace-1.0.

Suggested alternatives were :

• Use a special name .auto

        vos://service/path/.auto

• Use the / delimiter

        vos://service/path/

The decision was to go with the / path delimiter. I'm happy to go with this, with the following caveat.

Using the / delimiter for importing data into a new file is fine

        import into vos://service/destination/

generates a node in the destination container with a server generated name

        vos://service/destination/5116-780-145

However, the expected behaviour would probably be different for copying data from one location to another.

        copy vos://service/source/results.vot vos://service/destination/

I think the expected behaviour for this would be to inherit the file name from the source.

This would also apply when copying data from an external source.

        copy http://www.astrogrid.org/source/results.vot vos://service/destination/

both of which would create a node called results.vot in the destination space

        vos://service/destination/results.vot

I am happy to accept this, as long as everyone is aware of the different behaviour given the same destination URI.

Search API

It was decided that we would not be able to define a full query search operation in time for version 1.1. The two options were to define an interim simple search syntax for version 1.1 or defer the search API to a future version.

It was decided to defer the search API to a future version.

The current favorite seems to be to use some form of semantic reasoning queries based on RDF representations of the nodes and properties.

Access control list

Although this is important part of the VOSpace specification, we don't yet have a detailed proposal for how to implement this.

It was decided to defer this to a future version.

The current suggestions are to use (possibly a subset of) the XML syntax from WebDav^? to represent and manipulate ACLs, and to use some form of semantic reasoning language based on RDF representations of the ACLs to control permissions.

Container metadata

The problem is to distinguish between things like a container that will accept and store a zipfile as a child node, and a container that will accept a zipfile and unpack the contents, creating child nodes for each file within the zipfile.

The problem isn't to do with the import operation itself, it is more to do with how do we tell the client what options are available.

The simplest seems to be to add a list of views that can be used to construct child nodes.

        <!-- Views that can be used to construct child nodes -->
        <accepts-child>
            <view uri="xxx"/>
            <view uri="xxx"/>
        </accepts-child>

To make this more extensible, we could wrap this in a container element, leaving space to add additional container specific metadata later.

        <!-- Metadata about the container -->
        <container>
            <!-- Views that can be used to construct child nodes -->
            <accepts>
                <view uri="xxx"/>
                <view uri="xxx"/>
            </accepts>
            <!-- Space for other container related metadata -->
        </container>

Registration of protocol and view params

The problem with the protocol and view parameters occurs when we try to represent the state of a transfer as another Node in VOSpace.

Note - this does not mean that we have decided to represent transfer status as nodes ... yet. However, the problem with protocol and view parameters means that we can't experiment with this without mangling things to make them fit.

The current representation of a transfer uses a name attribute to identify the view and protocol parameters.

    <transfer>
        <view uri="[zipfile-view]">
            <param name="compression">8</param>
        </view>
    </transfer>

View and protocol parameters are registered as child elements of the view or protocol that they apply to. The parameter name only needs to be unique within the context of the parent view or protocol, which makes it difficult to create a URI that refers to a specific parameter.

The easiest way to represent the state of a transfer as a Node in VOSpace, is to make the view (and its parameters) properties of the transfer.

    <node uri="vos://service/transfer/71">
        <property uri="[view]">[zipfile-view]</property>
        <property uri="[???]">8</property>
    </node>

However, because a view parameter does not have a unique URI, we can't map the zipfile compression parameter to a node property.

The current registration schema defines parameters within the definition for the view or protocol.

    <!-- Definition of the view -->
    <key id="[zipfile-view]">
        <!-- Definition of the parameter -->
        <param key="compression">
            ....
        </param>
    </key>

The proposed solution is to modify the registration schema for view and protocol parameters, making them equivalent to node properties, with unique URIs for each parameter.

    <!-- Definition of the view -->
    <key id="[zipfile-view]">
        <!-- Reference to the parameter -->
        <param key="compression" uri="[zipfile-compression]"/>
    </key>

    <!-- Definition of the parameter -->
    <key id="[zipfile-compression]">
        ....
    </key>

Keeping the name attribute means that version 1.0 services can still refer to the parameter by name, but moving the parameter definition to a separate element means it now has its own unique URI that can be used in version 1.1 services.

This also means that the same parameter can be used in more than one view or protocol.

For example :

    <!-- A plain zipfile -->
    <key id="[zipfile-view]">
        <!-- Compression level -->
        <param key="compression" uri="[zipfile-compression]"/>
    </key>

    <!-- A Java jarfile -->
    <key id="[jarfile-view]">
        <!-- Compression level -->
        <param key="compression" uri="[zipfile-compression]"/>
    </key>

    <!-- Definition of the compression parameter -->
    <key id="[zipfile-compression]">
        ....
    </key>

-- DaveMorris - 16 May 2007