where next?

[Tony Linde]

Hi Bob,

> But I disagree with you that it is not suitable.  If we need 
> to add other metadata elements, fine, let's define them 
> through demonstrated use cases, not hypothetical arguments 
> about idealized structures that, as yet, have no drivers.

But we do have drivers: we want to store info on people, groups, projects
and organisations, non-sky services etc.

> My point about "small enough in number" is that if the number 
> of elements is too large, resource publishers will either 1) 
> not bother to fill them in, 2) fill them in with rubbish, 
> just to get on with things, 3) not bother to register at all. 
>  I do not agree that constraining ourselves to a moderate 
> number of metadata elements means that those elements will be 
> ambiguous or misunderstood.

I don't agree that the number of metadata elements is a problem IF they are
in separate branches of the hierarchy. If you use my tlRegistry03.xsd (naff
as it is) to create an xml file, each selection of a branch excludes all the
metadata elements in other branches. You only have to fill in relevant
information. OTOH look at the NVO prototype site and you have a huge number
of elements for every resource, no matter what type - that is why you get
errors.

> I think the only thing I agree with you about, Tony, is the 
> need to get others to join these discussions.

It's a start :)

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 21:17
> To: registry at ivoa.net
> Subject: Re: where next?
> 
> 
> Well Tony, I don't think I could disagree with you more!
> 
> > 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.
> The problem is that I do not believe it is "a little effort". 
>  We have been debating this for months already with no end in sight.
> 
> > 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.
> There is information in RSM that is not applicable to some 
> resources.  So what?  You can simply say "not applicable" and 
> get on with it, or spend a lot of effort trying to define 
> structures and substructures that avoid any "not 
> applicables".  I predict you will find a resource for which 
> some of the metadata you have blocked off is indeed 
> applicable.  I assert that you simply do not know, and will 
> not know, until you have assembled metadata for real 
> resources and worked with a prototype registry.
> 
> > 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.
> But I disagree with you that it is not suitable.  If we need 
> to add other metadata elements, fine, let's define them 
> through demonstrated use cases, not hypothetical arguments 
> about idealized structures that, as yet, have no drivers.
> 
> > 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.
> RSM is not just about sky coverage.
> 
> > > ... 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.
> Experience with other registries has shown that people will 
> always get things wrong.  We will need someone looking at the 
> registries from the VO projects to check on metadata quality. 
>  But I assert we will not know the extent of the problem, or 
> how to solve it, until we have real experience.
> 
> > >   I concur with Roy's view that we should aim for Dublin Core 
> > > compatibility, ...
> >
> > See separate message.
> A key point that distinguishes NVO from the other VO 
> initiatives is that NVO is the only one for which EPO is 
> major component.  For us, the connection to the Digital 
> Library community and users of the DL environment is 
> important. We need not be slaves to DC, but we should be 
> compatible where we can. Looking toward the future, when I 
> expect other VO projects to have to take EPO more seriously, 
> a clean and obvious consistency with Dublin Core is the 
> simplest way to go.  DC is not perfect, but it is in wide-spread use.
> 
> > > 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.
> My point about "small enough in number" is that if the number 
> of elements is too large, resource publishers will either 1) 
> not bother to fill them in, 2) fill them in with rubbish, 
> just to get on with things, 3) not bother to register at all. 
>  I do not agree that constraining ourselves to a moderate 
> number of metadata elements means that those elements will be 
> ambiguous or misunderstood.
> 
> I think the only thing I agree with you about, Tony, is the 
> need to get others to join these discussions.
> 
> Bob
>