where next?

[Tony Linde]

> the cart before the horse.  I think we need to build some 
> simple registries based on the RSM document and learn from 
> experience about how to ultimately structure information.  

Sorry, Bob, but I don't see why we would want to build registries on RSM
when, with a little effort, we can identify at least a few of the major
structures of the registry. I would have thought it was obvious that
curation and coverage are inappropriate metadata to apply to a person. We
should come up with an *approach* to defining the registry schema that takes
this type of thing into account.

I think that the RSM document is fine as far as describing sky-coverage
types of services but does not allow us to store other types of services nor
other types of resources. I think it would be wrong for this group to
publish a Working Draft which we know to be fundamentally unsuitable for
many of the resources we want to store.

I think we should concentrate on coming up with a flexible and extensible
structure for the registry metadata and then the RSM document could be
published within that structure as representing the schema for sky-coverage
service type resources.

> ... and already it is clear 
> that contributors are very inconsistent in their use of the 
> metadata elements.

Which is exactly my point in the previous email about using *appropriate*
names for metadata entities.

>   I concur with Roy's view that we should aim for Dublin Core 
> compatibility, ...

See separate message.

> 2) Make metadata definitions simple, clear, and small enough 
> in number so that curators can easily and accurately describe 
> resources.

I think your comment above about inconsistency shows what happens if the
number of metadata entities is reduced so that names are ambiguous and
misunderstood.

What you will end up with is web pages where the user is asked to select the
type of resource they want to list and the page logic then puts up
appropriate instructions for each of the ambiguously named metadata items.
The same applies to searches and software which uses the registry. We leave
ourselves wide open for mistakes in the data entered, in the writing of
programs, in the way the registry is searched etc.

I think the principles we should follow are:

A) structure the registry with a logical hierarchy of elements (but restrict
to 3/4 levels deep and 2/3 children per parent where possible)

B) name each item of metadata as unambiguously as possible (but use
complex-types to replicate common elements like names, addresses etc)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Robert Hanisch
> Sent: 16 June 2003 17:10
> To: registry at ivoa.net
> Subject: where next?
> 
> 
> Dear everyone,
> 
>   I contend that much of the discussion regarding the 
> structure of registries, metadata modules, etc., is putting 
> the cart before the horse.  I think we need to build some 
> simple registries based on the RSM document and learn from 
> experience about how to ultimately structure information.  A 
> major lesson I learned in the ISAIA project was that it was 
> very difficult to anticipate all metadata concepts, not to 
> mention finding some optimal structure, and that the best 
> practice therefore is to start with some working prototypes 
> and see how far you get.
> 
>   RSM is about metadata elements.  It does not define a 
> structure or dictate an implementation mechanism.
> 
>   I think by doing prototypes based on RSM we will learn 
> answers to the questions that have been raised, such as 
> whether or not certain metadata elements (Coverage..., for 
> example) make sense when applied to certain resources.  Last 
> week Mark Voit was working through some examples of RSM for 
> EPO resources, and you might be surprised to see how often 
> Coverage fields apply.  You have to think of the metadata 
> elements in terms of how users might pose queries to the 
> registry.  The primary function of the registry is to allow 
> information consumers (which may be computer programs) to 
> find resources.
> 
>   It was also interesting talking to Mark, seeing just how 
> confusing some of the metadata elements are already.  This is 
> criticial feedback, and information we will not get until we 
> implement and populate prototypes.  If we make things too 
> complex we will end up with registries filled with garbage.  
> I have been reviewing the RSM elements we have collected from 
> the cone search and SIAP services, and already it is clear 
> that contributors are very inconsistent in their use of the 
> metadata elements.
> 
>   I concur with Roy's view that we should aim for Dublin Core 
> compatibility, as this broadens the potential user base for 
> our resources.  This is especially important for our EPO 
> resources and their end-users.
> 
>   Thus, to me there are two guiding principles in the registry design:
> 1) Collect enough metadata to allow information consumers to 
> find a) complete and b) accurate lists of resources.
> 2) Make metadata definitions simple, clear, and small enough 
> in number so that curators can easily and accurately describe 
> resources.
> 
> Bob
>