role of the registry

[Matthew Graham]

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