role of the registry

Matthew Graham mjg at cacr.caltech.edu
Tue May 8 09:15:36 PDT 2007


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



More information about the dal mailing list