IDs and ID services

[Ray Plante]

On Mon, 3 Feb 2003, Tom McGlynn wrote:
> Key's can
> be used to build ID's but can also be used in other contexts.
> ...
> A key is no more than something which identifies an element
> of a set.  One can build more complex structures out of this.
> ...
> But if I have 10^9
> sources in my table, I'm unlikely to want to repeat the  40
> byte VO table identfier all 10^9 times.  

Ah, very good--I get it.  Very useful.  I think we can put this into a 
requirement.

As we talk about minimum interoperability requirements for the context of 
IVOA, we may find the need to segregate recommendations from requirements.

> It would be up to the
> user to decide whether they wished to consider the concatenation
> of the observation and format as the fundamental key, or just
> the observation itself.  We provide the user with sufficient
> information to enable them to decide sameness, we don't make
> that decision prematurely.  

I think in this example, the separation of these keys is appropriate.  My 
main concerns are:
  1.  The client needs to have a straight-forward, predictable way of 
      determining whether two objects are the same.  If an ID is formed by 
      combining keys, the client knows exactly where to get the keys 
      without knowing anything about the particular choices the provider 
      has made about what to give a key or what they represent.

  2.  The test for sameness enabled via IDs/keys is much easier/faster 
      than analyzing the specific metadata exactly.  This is not to say 
      that IDs encode all metadata information or that can cover all 
      interpretations of "sameness"; rather, for the most common cases 
      where a client might want to determine "sameness", an ID comparison 
      is useful as a first cut.

  3.  IDs can be used to obtain unique descriptions of things.  

I think a key-based approach as you describe it can address these 
concerns.

cheers,
Ray