RE: 2-stage identifier resolution

Sorry but I'm a little confused where this element comes into play with the Registry resource entity.. Does this mean each event is registered or is there a resource with a collection of events? I'm assuming since we've got to the detail of resolving uri's that it is the former. Trying to understand the scalability here with parsing, etc.

-Gretchen

-----Original Message-----
From: owner-registry-at-eso.org [mailto:owner-registry-at-eso.org] On Behalf Of Norman Gray
Sent: Friday, April 21, 2006 7:09 AM
To: Ray Plante
Cc: Roy Williams; registry-at-ivoa.net
Subject: Re: 2-stage identifier resolution

Ray

On 2006 Apr 20 , at 21.17, Ray Plante wrote:

> On Thu, 20 Apr 2006, Norman Gray wrote:
>> Quoth RFC3986, section 3.5:
>>
>> It's the client that dereferences the fragment: ``the fragment
>> identifier is separated from the rest of the URI prior to a
>> dereference, and thus the identifying information within the fragment

>> itself is dereferenced solely by the user agent, regardless of the
>> URI scheme.''
>
> I think this is satisfied. The user agent strips off the fragment,
> gives
> the IVOA ID to a registry and gets back a description containing a
> service
> endpoint. The agent then passes the fragment to that endpoint to
> get the
> part of the resource--i.e., one VOEvent record.

The '#' vs. '?' could potentially support the two-step v. one-step alternative that you described and Roy implied. Thus <ivo:// nvo.caltech/VOEventRepo#60601> is resolved in two steps, by the client resolving <ivo://nvo.caltech/VOEventRepo> and then querying for '60601' (as Roy said). But <ivo://nvo.caltech/VOEventRepo?60601> is potentially resolvable on the registry, as an added-value service, returning a VOEvent masquerading as a VOResource.

As a side issue:

It occurs to me that there's an alternative way of handling this. At the moment, IVO URIs are resolved via queries to a Registry service (these are still SOAP queries, aren't they?). The alternative is to have an ivo-to-http mapping defined, so that this URI maps to <http:// ivo.example.org/nvo.caltech/VOEventRepo> or <http://ivo.example.org/ nvo.caltech/VOEventRepo?60601>, which can be directly dereferenced, or passed around in software, to read the corresponding VOResource directly.

This is one of the ways (indeed, it may be the most common way) that DOIs are resolved. URI <doi:10.1145/945645.945664> can be resolved by turning it into <http://dx.doi.org/10.1145/945645.945664> and dereferencing it. Easy!

The extra goodness that could come this way is that by setting the HTTP Accept header, you can (by design) indicate the desired format of the result. Thus dereferencing <http://ivo.example.org/ nvo.caltech/VOEventRepo?60601> could return a VOResource _or_ a VOEvent depending on the Accept header.

> Which brings me to the my last point, which is most important.
> From the
> perspective of the IVOA ID spec, there is no difference between #
> and ?.
> So either should be fine. On the other hand, I do not perceive any
> possible disasters either.

Indeed, and I take the point that there are two specs relevant here.

For what it's worth, I don't see any specific disasters here either. But the point of coding in tune with a standard's assumptions and design is that you don't have to be imaginative. But if you code against a standard's design and assumptions, you have to think of the various ways things could go wrong, and the ways in which libraries, or proxies, or next year's clever thing will potentially mess things up or freeze you out. That's really all I was saying -- it wasn't meant to be a biggie.

All the best,

Norman

-- 
------------------------------------------------------------------------

----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK