Semantics of resource identifiers

An IVOA proposed recomendation describes the standard identifiers (also known as IVO Resource names or IVORNs) for IVO resources. That document states or implies these semantics for the namespace of identifiers; mainly, the stronger, more useful rules are implied rather than stated. I have written these notes to try to clear up some ambiguities.

Any URI with the scheme ivo SHALL be interpreted as an IVORN. Such a URI MUST conform to the syntactic rules for IVORNs. The URI may contain an IVORN, followed by a separator character ('#' or '?'), followed by some other identifier (hereinafter called the 'local resource name or LRN').

IVORNs are not URLs. The ivo scheme does not imply a transport protocol by which the resource may be accessed. Agents SHOULD NOT depend on implict mappings between IVORNs and URLs (e.g. replacing the ivo scheme with the http scheme in the URI to derive a URL for the resource.

An IVORN MUST refer to a registered resource. Resources MAY be registered before they exist, in which case agents may refer to them by IVORN. Agents in the IVO SHOULD NOT use URIs in the ivo scheme to name things that are not resources. However, using a composite URI that is an {IVORN,LRN} tuple is allowed.

In an {IVORN,LRN} tuple, the entity identified by the LRN is implied to be managed by the IVO resource. The resource controls the namespace of its LRNs.

An IVORN SHALL be unique within the IVO. An LRN SHALL be unique within its managing resource. Therefore, an {IVORN,LRN} tuple SHALL be unique within the IVO.

Each IVORN SHALL be resolvable to the metadata of the resource at an IVO registry. It MUST be known at least in the publishing registry where the resource was first registered. If an agent is given an IVORN to use then that IVORN SHOULD be resolvable at the agent's full registry of choice; i.e. IVO resources SHOULD be propagated between registries such that an agent needs to look in only one registry to complete its assignment.

An LRN SHALL be resolvable to information about some local resource managed the IVO resource that issued the LRN. However, the IVO resource NEED NOT provide any interface by which an agent may extract that information; handling of local resources can vary between IVO resources. The LRN MAY be opaque to all agents except the IVO resource that issued it, or it MAY have internal structure about which other agents may reason.

Notes:

• The acronym 'IVORN' is an AstroGrid coinage; I use it here for brevity. I take 'IVORN' to be a synonym of 'IVO identifier'; this may differ slightly from some uses in AstroGrid discussions where 'IVORN' was used to imply an {IVORN,LRN} tuple.

• 'LRN' is a new term introduced by this document.

• I use the term 'agent' to mean any software or human entity in the IVO.

• The formal handling of {IVORN,LRN} tuples, as above, is likely to be important for the VOSpace/VOStore and Single-Sign-On standards.

• Local resources refered to by LRNs have approximately the semantics of 'resources' in the WS-Resource-Framework (draft) standard of OASIS. It is reasonable for an IVO resource to use an {IVORN,LRN} tuple to identify a WS-RF resource that it owns.

-- GuyRixon, 2005-01-13