where next?

[Robert Hanisch]

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