Mark Taylor wrote:
>Dave et al.
>
>I'm total VOSpace newcomer so there's a high probability that some or
>all of the comments below are ill-informed and/or nonsense
>
Not at all, you have highlighted some important gaps where I haven't
explained in enough detail.
> CreateNode
> - what's it for? What is the meaning of an empty node? Can't you
> just get by with ImportInit?
>
You are right, the import methods can be used to create new data nodes.
However, create node is required to create other types of nodes, such as
containers and symbolic links.
I've added a line to the create node page 'This is used to create new data nodes, containers and links'
> Data formats such as ivo://org.astrogrid.vospace/formats/votable-1.0
> - why not use MIME types?
>
>
In order to exchange information about data formats, we need a common
list of formats and protocols that all VO applications use.
In the VoSpace specification we have defined <format> and <protocol> as
URIs.
Exactly what is in those URIs is open to debate.
I used registry URIs, because they can be resolved to a description
about the data format.
At the moment, I have just created a basic <resource> for each, but this
should be expanded to include details of the format, it's specification,
and details of how it is used in astronomy.
If another VO group proposes a new data format, then they can register a <resource> document describing how the data format works. If your application received some data in the new format, and you didn't know what was; then you should be able to look up the URI in the registry to find details of what the format is and how to handle it.
It also allows us to create more specific sub-types if we want.
For example, as I understand it, FITS can contain a wide range of data,
from simple tabular data to binary images.
A database table based VoSpace might be able to interpret the tabular
data, but it might not be able to handle embedded images.
In which case, the service would accept 'fits.tabular', but not
'fits.image'.
A file based VoSpace that does not interpret the data, would accept any
format and store it as a BLOB.
We probably could use MIME type for this, but would it be specific enough to distinguish between tabular and binary FITS, or different versions of VoTable ?
Also, if we used MIME type to identify data formats, what would we use
to identify transport protocols ?
Using URIs, preferably registry URIs, means we can use the same system
for data formats, transport protocols ... etc.
> - "Should we make the default format binary and allow the <format>
> element to be optional?"
> - I'm inclined to answer "yes", but that may be because I don't
> understand the purpose of them.
>
>
We would like to encourage people to add as much metadata as possible
when importing data into VoSpace.
If the client specifies a data format, then future VoSpace services can
decide how to interpret the data based on the format.
Always defaulting to 'binary' means we end up with a large pile of 'stuff'.
It all depends on how people want to use the system.
They may find it tedious to have to specify the format whenever they
import data.
On the other hand, if they do specify the format, then VoSpace clients
could provide a much richer UI showing different icons and options for
known data formats.
> CopyNode in continuation mode:
> - Specify the semantics of PageSize more precisely - is this a maximum,
> or an exact requirement for the server for every page except the
> final one?
>
>
Good point.
I've added this as a question on the page.
As a UI developer, which would you prefer ?
> ListNodes
> - is incorrectly titled "CopyNode"
>
>
Yep, copy/paste error .. page updated.
> - Returns | Properties
> - In "The set of name value properties for the new node", "new"
> is presumably a typo
>
>
Yep, copy/paste error .. page updated.
Thanks,
Dave
Received on 2006-04-28Z14:07:05