Jumps: IvoaResReg :: registry mail archive :: ResourceMetadata :: RWP03RefBack :: RWP03Disc

Registry Working Group WP3 (Metadata Specifications)

Discussion of PR IVOA Identifiers v1.1

The Proposed Recommendation for IVOA Identifiers was posted 21 June 2004 in the IVOA document repository. Comments regarding issues that should be considered before this standard is elevated to an IVOA Recommendation should be posted here by 31 July 2004.

The above was never followed up. New close date is 20th Feb 2005.

When adding comments, be sure to include your name and the date and divide each with a "---".


I found a number of typos and grammar errors, and suggest that these be fixed. I have no objections to the document otherwise. -- BobHanisch - 09 Feb 2005


IETF URNs have a specific syntax described in RFC2141. The proposed syntax of our resource identifiers is different although the semantics are the same. That's OK, but we should avoid calling our identifiers URNs.

-- GuyRixon - 20 Feb 2005


Our identifiers are in two parts, the global part and the local part, separated by (typically) a '#'. We need names for these parts to aid discussion. I suggest naming the global part the International Virtual Observatory Resource Name (IVORN) and the local part the Local Resource Name (LRN). Formally, neither includes the '#' separator. These terms should be defined in a new section 3.1.3. I'll use these terms in further comments below.

-- GuyRixon - 20 Feb 2005


In section 3.2.2, clarify the rules for usage of the URI. Something like this:

Any URI with the scheme ivo SHALL be interpreted as an IVO resource identifier. Such a URI MUST conform to the syntactic rules for these identifiers.

IVO resource identifiers 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.

-- GuyRixon - 20 Feb 2005


Clarify and strengthen the rules for creating the identifiers. I suggest adding this at the end of section 3.3.
An IVORN MUST refer to a registered resource. Agents MUST NOT refer to unregistered resources by IVORN. 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.

-- GuyRixon - 20 Feb 2005


Clarify and strengthen the rules for uniqueness of resources. I suggest adding this as a new section 3.5 "uniqueness".
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.
TonyLinde suggested on the list that we can't mandate the use of the LRNs; in that case, the SHALLs in the second and third sentences above become SHOULDs. However, the PR text mandates that identifiers with matching authority and resource key must point to the same resource, so I think the stronger form holds; we do control the use of the LRN to this degree.

We do need to be clear, however, about what we mean by unique. I suggest that section 3.5 continues thus:

In this context, "unique" means that a given identifier SHOULD not be associated with two different resources at any instant, but that the resource associated with an identifier MAY change with time. If a registry accepts a new resource description associated with an existing identifier, then the registry SHALL replace the old description with the new one and SHALL NOT propagate both versions of the description. Note that, due to the latency in propagation between registries, two different registries may associate different resources with an identifier at a given time. The rate of change of resource descriptions is expected to be sufficiently slow with respect to propagation of those descriptions that the latency is not a problem.

The creator of an identifier MAY treat that identifier as unique for all time; in this case, the creator registers a new identifier when the resource description changes and deletes the old identifier from the registry. However, creators of identifiers NEED NOT work in this way and most will update resource descriptions without changing the identifier. Therefore, agents receiving an identifier MUST NOT assume that it identifies a unique version of the resource or the resource's description.

-- GuyRixon - 20 Feb 2005

'Fraid I don't agree. The use of an LRN is entirely up to the owner of the associated resource: if we cannot say anything about it we shouldn't say anything about it. I also find 3.5 more confusing than illuminating.

-- TonyLinde


Clarify the semantics of resolving an identifier. I suggest adding a section 3.6 for this, with content as follows.
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; e.g., the LRN might express a hierarchical directory-structure in a virtual file-system, inviting agents to traverse this structure.

If an identifier with an LRN is resolved to metadata at a generic registry, then the registry MAY ignore the LRN; i.e. metadata for local resources are not propagated normally between resource registries. An agent MUST NOT assume that an arbitrary registry distinguishes local resources.

If an identifier with an LRN is supposed to be resolvable to metadata specific to that local resource by agents other than the issuer, then the IVORN SHOULD allow the agents to find the service that can do the resolution. Either the IVORN identifies a resolving service directly; or the IVORN identifies a resource whose metadata nominate an associated resource which is the resolving service.

Agents MUST NOT use IVORNs simply as a namespace for LRNs. An agent MUST NOT emit to the VO an identifier with an LRN unless the IVORN of that identifier maps to a registered resource.

-- GuyRixon - 20 Feb 2005

Again, I don't see a need for this. An IVORN can be registered at either a publishing or full registry. Again, we should say nothing about LRNs: they are not resolvable within the context of what we're discussing here.

-- TonyLinde - 20 Feb 2005


Clarify and strengthen the rules for creating LRNs. I suggest adding this to section 3.3:
In an {IVORN,LRN} tuple, the entity identified by the LRN is implied to be managed by the IVO resource named by the IVORN. The resource controls the namespace of its LRNs.

-- GuyRixon - 20 Feb 2005


Edit | Attach | Watch | Print version | History: r16 | r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r11 - 2005-02-20 - TonyLinde
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback