role of the registry

[Tony Linde]

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

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