Resolving IVO Resource Names

See also CommunityIdentifiers, LocatingVOThings

IVORN

An IVORN is what is sometimes called an 'IVO identifier'. In fact it is just a name (see this) for a resource; a registry is used to look up that name and return a resource description. It is of the form:

   ivo://anything[/something[/something/etc[#somefragment]]]

It is simply an index key that is used to look up a VODescription in the Registry. The tokens between the slashes can be anything at all; the split-by-slash is for human convention use only and has no software 'meaning'. The fragment following the '#' is not part of the key.

Referring to a file using an IVORN

An IVORN can be used to locate a particular file; for example a registry may return a URL when given an IVORN. However it is unlikely that registries will hold indexes to every single file.

Furthermore, IVORNs can refer to things other than files or storepoints; an IVORN might refer to a datacenter for example, or a person. There is no type information associated with a bare IVORN.

We identify a file like this:

   ivo://some.key#path/to/file.txt

where ivo://some.key should name a store point, and path/to/file.txt specifies the path on that storepoint to the file.

AGSLs

AstroGrid Storepoint Locators are locations. They are like URLs but are not Universal; they do however provide all the information you need to connect to an existing file, or to locate the place where a file will go. They are of the form:

   astrogrid:store:<urlToServerRoot>#path

or

   astrogrid:store:myspace:<delegateEndpoint>#path

They can be used to identify sources/targets when the store points are not Registered, and they are used internally to the store delegates to represent the locations that IVORNs resolve to.

Resolving IVORNs to AGSLs

So a file might be named using an IVORN like this:

   ivo://some.key#path/to/file.ext

To find out what service to connect to, we make a call to the registry to get the service endpoint, and we recombine this endpoint with the fragment to get an AGSL, eg:

   astrogrid:store:myspace:http://grendel12.roe.ac/services/MySpace/Manager#path/to/file.ext

This is straightforward, although we should cope with what happens if the VODescription/endpoint returned is not a storepoint.

Resolving Accounts to AGSLs

On Astrogrid, there is also the concept of 'personal home space'. Therefore we can talk about a file in 'my home' or 'Keith's home', etc.

At the moment we use the IVORN syntax to identify the account:

   ivo://community/individual

   ivo://roe.ac.uk/mch

This leads to all kinds of confusion both for users and for the resolving software.

Proposed changes

Change community scheme

Give the account identifier a different 'scheme' (the bit before the colon). Therefore we specify an account like this:

   account://community/individual

   account://individual@community

a file in an individual's homespace would be identified using the similar 'fragment' scheme to IVORNs and AGSLs:

  account://individual@community#path/to/file.ext

Add consistent file identifier scheme

Add a new prefix to all three types ( astrogrid:store:, ivo: and account: ) to show that we are identifying a file. If it really is very temporary, we could just add 'vospace:' to the front. However it might be better to make them a little more consistent with where we expect to go with LocatingVOThings, so I propose:

astrogrid:file:ivo: for a Registered file with an IVORN

astrogrid:file:account:@# for a file in an account's homespace

astrogrid:file:url: for a file that can be reached using a standard url

astrogrid:file:myspace:# for a file in myspace specified by a delegate endpoint

astrogrid:file:myspace:ivo:# for a file in a myspace server specified by an IVORN

astrogrid:file:null: for the equivelent of '/dev/null' - output is thrown away

The astrogrid: scheme identifies the URI as one of our forms; the file: tells us we are identifying a file, not a service. (This maps to the idea of identifying a table: as well)

This will involve some kind of AGFI (Astrogrid File Identifier...) to represent the above, and removing AGSLs altogether. AGSLs would be replaced by the existing URLs and MSRLs (MySpace Resource Locator).

Problems

1. How do we make sure paths get concatinated properly? eg from account -> homespace -> agsl?
2. The 'scheme' doesn't work properly when we make use of the fragment; ie, we use account://mch@roe.ac.uk to identify an account. Having the same account: scheme when identifying an account account://mch@roe.ac.uk#path/to/file.ext is not quite right.

These should all be solved using the new LocatingVOThings.

-- MartinHill - 08 Mar 2004