resource identifiers
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Tue May 27 22:09:38 PDT 2003
Hi (again) Tony,
I think this is probably a good time to explicitly clarify the
requirements that described thus far only informally. I believe our
working set to be the following:
1. A VO identifier can be used to obtain a unique description of a
resource from a registry. A VO ID is, thus, necessarily globally
unique.
2. The spec defines a uniform framework for encoding all VO identifiers
3. Identifier encoding should be compatible with the URI specification
and integrate well into XML documents. The latter includes making it
easy to extract an ID from an XML document.
4. The identifier framework should provide a way to refer to components
of a resource (e.g. a catalog record) that is not necessarily
described in a registry (though its resource would be). The component
identifier need not be permanent and may only be applicable within a
limited context.
All four of these are informally stated in the message that started this
thread. Req. 4 is the point we are discussing now. I also note that we
have approached 3 by specifying two formats for an ID that are
inter-convertable: an XML-tagged version and a URI version.
On Tue, 27 May 2003, Tony Linde wrote:
> If you mean that resources with a RecordKey are not stored in the registry
> then that's okay. In which case, RecordKey should not be part of the
> ResourceID. Maybe you need to wrap Resource ID in another structure, eg:
>
> <RaysBitsID>
> <ResourceID>
> <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
> <ResourceKey>ADIL/SIA/targeted</ResourceKey>
> </ResourceID>
> <RecordKey>95.DR.01.01.fits:wibble</RecordKey>
> </RaysBitsID>
I gather that <RayBitsID> is part of some specific schema intended for a
limited use and not part of a VO standard schema. The fact that
<RecordKey> is a part of <RaysBitsID> and not part of <ResourceID>
suggests that we no longer have a uniform way to refer to records or other
components of a resource. Each specialized schema is free to handle this
reference in its own way.
If that is the intent, then we should consider dropping Req. 4.
Before we do, though, I would suggest that the RecordKey is not so scary
an item as it seems. I think it fits very nicely into a simple framework
based on two interchangable encodings:
XML ResourceID Node <==> URI
That is, the contents of the <ResourceID> can be convert to a URI and back
again independent of any other metadata. Adding the RecordKey does not
break this model; rather, it provides further consistancy with URIs with
the use of # to mark the resource component. Furthermore, including it
within <ResourceID> incurs no further cost to consumers of the XML form.
For example, if a registry wants resolve it to a description, it grabs the
<ResourceKey> and (when needed) the <AuthorityID>, just as it would
otherwise.
Since I was the originator of Req. 4, I should say that I have some
specific use cases in mind. SIA V1.0 has a preliminary (and as yet
unimplemented) specification for a staging request which includes a
reference to one of the images refered to in a prior image query. An ID
containing a <RecordKey> would allow one to refer to the particular image
to stage. Another is one generated by Roy where in his response to an
SIA image query (which is in VOTable format) he might include an extra
table that describes where to access mirrors of the images; IDs for the
images would link to two tables. While he would not necessarily need a
globally unique ID to accomplish this, we can consider generalizing this
scheme to any case where identical data is located at multiple places and
in which the "mirror table" is passed in a separate message; then a
globally unique ID is useful.
So, do we drop Req. 4? If so, what are the specific objections (e.g. cost
of processing, inconsistant model)? Or, do we address it in a different
way?
cheers,
Ray
More information about the registry
mailing list