Note, these were some ideas that made sense when I wrote them. Since then, I have done some more work on implementing VOSpace 1.0 and 1.1 services, and the discussion has moved on.

-- DaveMorris - 30 Apr 2007

Proposed changes for VOSpace 1.1

The aim of version VOSpace 1.1 is to add support for hirearchical directories and inter space links.

There are a number of other things that need looking at, specifically views, data formats and protocols, but these are all less well defined and will have to wait for future versions.

Key changes are :

• Adding support for hierarchical paths
• Adding new node type for LinkNode
• Adding new node type for ContainerNode

New node types

I originally argued that we could get away without defining new data types, but having looked at implementing the rules behind it, I can see there are distinct behavious that need some form of type mechanisim.

Link node

The simplest form would be to make the new type extend the base class NodeType.

• LinkNodeType extends NodeType

If we add add a specific XML element to LinkNodeType for the link target, then it should probably be defined as xsi:anyURI.

There are +ve and -ve sides to adding a new XML element. At the moment, all of the node types share the same XML structure.

If we don't define a new XML element for the link target, we can acheive the same behaviour by defining a specific link target property.

On the other hand, in theory all LinkNodes should have a target (even if it is null), and explicitly defining this as an xsi:anyURI element may be useful.

Open to discussion on this one.

Container node

The simplest form would be to make the new types extend the base class NodeType!.

• ContainerNode extends NodeType

There has been some discussion about adding some form of XML attribute that indicates if a container node has any children. This would act as a 'hint' to the client, to enable it to decide if it is worth sending a ListNodes request or not.

I would prefer not to include an explicit count of the child nodes, as this could cause complications on the server side, having to scan the back end database and count the child nodes every time a client looked at the container node.

The rules about which types of node may or may not have child nodes is not clearly defined at the moment.

The obvious rule is to say only ContainerNode nodes are allowed to have child nodes. However, this excludes some interesting possibilities that I would like to experiment with in the future, and I would prefer not to make this explicit unless we have to.

One possible use case is where a user uploads a zip file to a DataNode. The service stores the data as a zip file, but has the capability of looking inside the it and representing the contents as a tree of nodes.

There may be other use cases dealing with how we represent database tables. I haven't fully explored these yet, but I would rather not exclude them at this stage.

.... more to think about here ....

The more that I look at this, case for an explicit ContainerNode is less clear than it is for LinkNode. In many cases, (zip files and database tables in particular) the distinction between DataNode and ContainerNode is more than a little fuzzy.

New fault types

Link found fault

To support LinkNodes, we would need to add a new fault LinkFoundFaultType, which is thrown when a client attempts an operation on a LinkNode that should be applied to the link target.

New URI for auto generated names

The current vos://null idenifier does not scale to handle a system with a hierarchical directory structure. At the moment, there is no facility request an autogenerated name in a specific directory. In addition, it is not clear to end users what 'null' means.

I would suggest we replace this with a reserved node name .auto, which can be used in any directory.

So

    vos://service/frog/toad/.auto

would mean create an auto generated name in

    vos://service/frog/toad/

If a client sent the following to CreateNode or one of the data import methods :

    <node uri="vos://service/frog/toad/.auto">
        ....
    </node>

The service would generate a new name for the node and respond with something like this :

    <node uri="vos://service/frog/toad/5178-AF20">
        ....
    </node>

Promote accepts and provides to top level node

I would like to promote the accepts and provides elements from DataNodeType to NodeType.

There are several reasons for this, but primarily because I would want to be able to provide different views of other types of nodes.

I don't want to re-open the discussion about views and formats, that will have to wait until later. At this stage, all I would like to do is allow a service to provide accepts and provides lists for any type of node, not just DataNode.

Transfer container as single entity

One use case for having accepts and provides lists for a ContainerNode is to provide support for transferring the entire contents of a directory in a single transaction.

The best way to do this would be to offer zip or gzip views of a ContainerNode.

Moving the files one at a time is fragile if the data transfer fails part way through the process the system could end up with some files transferred and some not.

Moving the entire set as a single zip or gzip file either transfers everything, or none, making the transfer more reliable.

As far as the user is concerned, the individual files and tree structure appears to move from one service to another, with the sending and receiving services packing and unpacking the individual files in the background.

This would also be useful for creating a backup of a section of a VOSpace tree as a zip file with the node metadata supplied in an additional metadata file. Much like a Java jar file extends zip, but adds Java specific metadata in the META-INF directory.

RDF and OWL views

As part of our work on using reasoning tools to describe and discover resources, I need to provide RDF, OWL and RSS metadata views of objects within a space.

These are not 'data transfer' views, they are 'semantic' views of objects in the space, but they still qualify as views, perhaps more so than some of our current views (which are more like data formats).

In theory, I could expose these as node properties, but I would also like to be able to list them in the provides list of views.

These 'semantic' views would apply to all types of node, including LinkNode and ContainerNode.

• An RDF or OWL view of a LinkNode could describe the LinkNode as 'containing' the entity refered to by the link URL.
• A 'semantic' view of a ContainerNode that contained a set of LinkNodes could be described as containing all of the entities referenced by each of the LinkNodes.

Both of these use cases allow us to provide more functionality in VOSpace 1.1 without actually adding any new XML elements. The only change this would require is to move the (optional) accepts and provides elements from DataNodeType up to NodeType.

-- DaveMorris - 18 Apr 2007