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 "---".

---

A pending version incorporating feedback posted here is available as Identifiers-20050302.html. Please see my comments below for a summary of the changes over PR v1.1.

-- RayPlante 03 Mar 2005

---

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

Thanks for the corrected .doc version; corrections have been incorporated.

-- RayPlante - 25 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

I agree. I'll adjust language accordingly. I'll note that URN is only referenced in the Definitions section, and not in the main spec.

-- RayPlante - 24 Feb 2005

Having looked more carefully at the text (and given my note above), I've not made any changes to address this. The introduction explicitly states that this proposal does not address location-independent names, the realm of URNs.

-- RayPlante - 25 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

I like your IVORN suggestion, although I'm partial to IVORI.

Note, however, that this spec on purpose does not specify what the role of what comes after a # or ?; although, it is being used for LRNs, as you call them. This is the result of direct feedback from reviewers. A group average of the reason why is that it was considered too early to set this in stone, yet.

I would like to eventually see this standardized in the way you describe; however, given the past discussion, I would prefer not to stick it into a revision for PR->Rec promotion. More review would be appropriate.

Given that the LRN is being tabled, I would rather not switch whole-hog to a IVORN as official jargon (especially since IVOID is in common VO parlance now and shows up in things like an XML attribute "ivo-id"). I will adjust the language to a bit to transition us toward this in anticipation of a v1.2 that addresses LRN.

-- RayPlante - 24 Feb 2005

I've changed the parlance generally to IVOA resource identifier throughout. Where this term is defined, I indicate synonyms:

An IVOA Resource Identifier (or IVOA identifier or IVOA ID for short) is a globally unique reference....

One of the shortened versions is sometimes used soon after the long version to make the style less clunky.

-- RayPlante - 25 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

I'm okay with this. I'll adjust with slight edits. Agents run by the publisher is free to assume a mapping to a URL for his/her own IDs.

-- RayPlante - 24 Feb 2005

At the end of 3.2, I've added:

It is important to note that an IVOA resource identifier in URI format is not a URL. The ivo scheme does not imply a transport protocol by which the resource may be accessed. Agents, in general, should not depend on implicit mappings between IVOA resource identifiers and URLs (e.g. replacing the ivo scheme with the http scheme) to derive a URL for the resource. Resource publishers, however, may support such a mapping between identifiers and URLs that they manage; in this case; agents should only assume the mapping applies within the domain of the publisher.

-- RayPlante - 25 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

I'm okay with this strengthening (though I would drop the reference to LRNs).

-- RayPlante - 24 Feb 2005

I've added to the end of 3.3:

Since IVOA resource identifiers refer to a resource that has been registered (see definition), providers and software agents should avoid referring to unregistered resources via an IVOA identifier. In practice, there may be some time lag between when a resource is available and when it is actually published; in this case, any use of the identifier should based on the expectation that the resource will be registered soon.

-- RayPlante 25 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

I think some strong statements regarding uniqueness a kin to what you suggest would be useful. We should not endorse the reuse of resource identifiers (that is, allowing the publisher to switch the association to a logically different resource), only the update of the resource descriptions. What constitutes the difference between reuse and update is up to the publisher's discretion. Thus, I would make use of SHOULD and MAY differently.

-- RayPlante - 24 Feb 2005

At the start of section 3.3, I've inserted the following:

An important aim of the process for creating identifiers is to ensure uniqueness. In the context of IVOA resource identifiers, "unique" means that a given identifier MUST NOT refer to two different resources at any instant. Furthermore, the identifier SHOULD refer to one logical resource over all time; that is, IVOA identifier should not be reused. The description of the resource referred to by the identifier, however, MAY change over time. What constitutes the difference between re-use of an identifier and an update of its description is left up to the discretion of the publisher.

---

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

Ditto regarding LRNs. Also, there are a bit too many references to the details of registries of how registries operate (which is governed by another standard or two which are not even to PR stage). I prefer the statement from 3: An IVOA ID always refers to a resource that has been registered with an IVOA-compliant registry.

-- RayPlante - 24 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

In summary, I see LRNs as out of scope of this version, but it would be a great motivation for a version 1.2. I will strengthen language in various areas a bit, and send you (Guy, Tony) a copy before submitting to the exec for promotion.

-- RayPlante - 24 Feb 2005

Added note box about dataset identifiers in response to email discussion with Guy.

-- RayPlante - 03 Mar 2005

---

Some more comments.

1. In the Introduction is written: "This proposal defines identifiers of the first type describe above--that is, organization-dependent identifiers". But in sec. 3 (Specification) it says: "An IVOA Resource Identifier (or IVOA identifier or IVOA ID for short) is a globally unique reference to a resource represented in a compact, ASCII-text format".
   

Probably the introduction bit should be updated to reflect the fact that IVOA-IDs are globally unique - at least within the IVO.

1. Again on introduction: what about replacing "proposal" with something like "document" (better for the Rec status)?
2. The XML schema and the document itself seem to be out of synch. For example, the <ResourceID> tag is not used any more.
3. The list of reserved characters (sec. 3.1.1) is almost the same as the one defined in the URI Internet standard. It would be nice to have exactly the same set of reserved chars, especially the "+" and the "=" are completely missing (plus some other are only discouraged).

-- MarcoLeoni - 11 Aug 2005

---