role of the registry

[Tony Linde]

Hi Matthew,

 > Don't worry, I'll be fighting shoulder-to-shoulder with you on the
 > barricades before the registry is killed or indeed replaced. What we

Great to hear.

And I agree that future uses of the VO might mean separating the detail 
metadata from the registry entirely, even in the AstroGrid system. But 
for now, to match the responsiveness of existing applications while 
extending their functionality into the VO arena, we must be able to 
provide those apps with detailed metadata at the same time as the 
location and core-level metadata. What we cannot do is provide users 
with more functionality (able to get at any dataset anywhere) but at the 
expense of having to sit around and wait while the app gets the detail 
metadata after they've selected their datasets.

Even in the future when we have these radically new search techniques, I 
really do not think we will lose the need to cache detailed metadata 
alongside the core stuff. Let's face it, Google does not just store the 
location of pages with their titles, it stores fully detailed metadata 
about every single page. It is only when you go to the page itself that 
you might see slight differences based on cache vs actual.

Cheers,
Tony.

Matthew Graham wrote:
> Hi,
> 
> Tony Linde wrote:
>> > metadata stores or we can separate these and keep the registry simple
>> > and create a different kind of infrastructure for the data dictionary
>>
>> I have no problem with conceiving of splitting the location and 
>> description roles of the registry but let's not kill the registry 
>> *before* we've implemented its replacement.
>>
>> T.
> Don't worry, I'll be fighting shoulder-to-shoulder with you on the 
> barricades before the registry is killed or indeed replaced. What we 
> have at present serves its function (or would if all the metadata were 
> actually filled in properly) but it is possibly not the natural 
> repository for data dictionaries. I contend that these require a 
> different kind of search strategy and a scenario I can envisage would be:
> 
> 1. User queries a registry for a data collection/service that matches 
> some general constraints: general subject matter, spatial coverage, etc.
> 2. The registry returns a set of resource records describing these 
> resources and where relevant one of the pieces of metadata is the 
> location of the data dictionary for the resource. The data dictionary 
> could be inline in the registry record for simple cases or it could 
> point to another specific service that is serving this information.
> 3. The user queries the data dictionary service for the nitty-gritty 
> details of the data model that the resource is providing.
> 
> Whether the data dictionary service is a new type of capability for 
> certain registries or an entirely new type of store (e.g. a VOSpace) is 
> really an implementation detail. I guess what I'm saying is let's define 
> the interfaces first: how does a resource provide its data dictionary, 
> what form is the data dictionary expressed in and what is the search 
> interface for querying stores of data dictionaries before worrying about 
> whether we should do this in the registry.
> 
>    Cheers,
> 
>    Matthew
> 
>> Matthew Graham wrote:
>>> Hi,
>>>
>>> I'm inclined to agree with Bob. We invented the registry as an 
>>> alternative to UDDI, which did not do exactly what we wanted, for 
>>> resource discovery and not as a generic metadata store. As I have 
>>> said before, we can overload the registry concept and use the 
>>> existing infrastructure (plus some epicyclic extensions) to provide 
>>> general metadata stores or we can separate these and keep the 
>>> registry simple and create a different kind of infrastructure for the 
>>> data dictionary stuff.
>>>
>>>    Cheers,
>>>
>>>    Matthew
>>>
>>>
>>>
>>> Robert Hanisch wrote:
>>>> I don't really have the time right now to engage in this lively 
>>>> debate, but
>>>> it does bother me to see history being rewritten in order to support 
>>>> certain
>>>> points of view.
>>>>
>>>> The registry was conceived as a resource location service.  The 
>>>> formative
>>>> document describes resource metadata.  The name of the working group is
>>>> Resource Registry.  There has been debate for a long time on how far 
>>>> to push
>>>> the registry in the direction of detailed service-level metadata.  The
>>>> origins were simple, however.  The "radical change to the way the VO 
>>>> works"
>>>> is coming from adding increasing complexity and overhead to a simple
>>>> concept.  This is not unique to the registry, but it is clear in the 
>>>> case of
>>>> the registry that even the simple stuff is not done well or completely.
>>>>
>>>> I have never been convinced by the arguments for including things 
>>>> like table
>>>> column names and UCDs in the registry.  The use case recently cited, 
>>>> that of
>>>> dynamically building SEDs by locating catalogs with relevant columns 
>>>> would,
>>>> I think, never be trusted by astronomers doing research.  They trust 
>>>> NED
>>>> SEDs because astronomers working for NED collect and curate the
>>>> measurements.  In the VO case, they need to assess the quality of a 
>>>> resource
>>>> before deciding to use/trust its contents.
>>>>
>>>> I suggest that everyone take a deep breath, step away from their 
>>>> desks for a
>>>> while, and try to recall what the VO is really about.  Key issues 
>>>> are data
>>>> discovery, interoperability, and a low barrier to participation.
>>>>
>>>> This should be an interesting Interop meeting!
>>>>
>>>> Bob
>>>>
>>>>
>>>>   
>>>
>>
> 

-- 
Tony Linde
Phone:  +44 (0)116 223 1292    Mobile: +44 (0)785 298 8840
Fax:    +44 (0)116 252 3311    Email:  Tony.Linde at leicester.ac.uk
Post:   Department of Physics & Astronomy,
         University of Leicester
         Leicester, UK   LE1 7RH
Web:    http://www.star.le.ac.uk/~ael

Project Manager, EuroVO VOTech   http://eurovotech.org
Programme Manager, AstroGrid     http://www.astrogrid.org