Registry WG: Attention/Action

[Ray Plante]

On Mon, 16 Jun 2003, Tony Linde wrote:
> 1. Should the RSM document be a Working Draft (WD), ie a document approved
> by this group as the basis for a future standard?

I'm not sure the what follows "ie" above is consistant with the definition 
given in the Document Standards document.  In particular, a WD "is not an 
assertion of concensus, of endorsement, or of ... quality," nor it is 
intended to meet all requirements.  It *can* be unstable and *is* intended 
to go through many versions.  

I see a WD as a working draft that can be used to gather ideas and solicit 
feedback.  Can there be multiple WDs?  Sure.  

At this point, I think that whether it is a WD or a Note is of little 
practical consequence, since either may change radically before making it 
to the PR stage.  

[Note: while the Doc Stds doc mentions Notes, it does not appear to define 
them.]

> 2. Should RSM (Resource and Service Metadata) be renamed to RM (Resource
> Metadata)?

I think this is a minor issue hardly worth worrying about at this stage.  
We can change it later. 

> 3. What structure should the next WD take: a flat one based on Ray's
> VOResource.xsd or a hierarchical one similar to the one's I've posted
> recently?

Please note that VOResource is hierarchical (see example, 
http://www.ivoa.net/internal/IVOA/IVOARegWp03/adil.xml); however, it 
is indeed flatter than Tony's suggestion.  It is a little difficult to 
compare the hierarchy though since they handle "is-a" and "has-a" 
differently.  Tony's next version may clarify this more, though.

Overall, I prefer a flatter hierarchy, because I tend to think that it
will adapt more flexibly to changes and additions in the future.  
(Flatter tends to map more easily to RDB tables.)  I think that Tony would
like to see a bit more comprehensive design up front, which is not so
unreasonable.  Nevertheless, I'm reticent to lock in parts of a model
we're not really ready for yet.

> 4. Should the metadata for a resource be unambiguous and each item named for
> its purpose or should we have a basic set of metadata which is used to fit
> requirements of different types of resource?

I don't think this question is sufficiently well defined.  I've discussed 
the advantages of limiting the precision of definitions for interoperating 
across diverse resources, but certainly you don't want too much ambiguity.  
It's a question of balance that I think we are learning about by trying to 
apply the current definitions in the RSM.  There are problems with the 
defintions and perhaps the names that need to be addressed.

> 4a. Should the basic resource metadata be based on Dublin Core or should
> metadata items be named for their astro meanings (and transformed to DC form
> if needed for DC-tools harvesting)?

In our initial attempts we've tried to stick closely to DC to help ensure 
that we can not only interoperate at some level with the digital library 
community, but also not reinvent the wheel.  However, a case can be made 
for the latter idea of just making sure we are transformable to DC.  I 
think attempting to apply RSM to a variety of resources will help 
demonstrate how far we can go with a close paralleling of DC.  

> 5. Should the group discuss the structure of resource metadata now and only
> issue a new WD when that discussion is more stable or should we issue a new
> version of RSM/RM and get people to build software based on that proposal
> and then discuss the structure?

Our mantra for the Cone Search and SIAP implementations have been that 
these are just prototypes that can be thrown away when the specs are 
revised.  The fact that these prototypes have been done by those within VO 
projects and not the "outside world" means that we don't have to worry too 
much about deprecating them.  The benefit is that we've learned a lot from 
implementing and using these prototypes.  They have gotten lots of 
criticism which are all being addressed at some level in subsequent 
versions, planned and in the works.  

Whether people build software prototypes based on the RSM depends mostly 
on how it fits in with the demands of the individual projects.  
Nevertheless, the more projects can afford to participate, the more we can 
learn.  I think also there is desire for us to demonstrate to the 
science community joint development across projects in the form of working 
demonstrations, as opposed to joint documents; international prototypes 
can serve this purpose.  

cheers,
Ray