Schema 0.8.3

[Robert Hanisch]

There has been a lot of e-mail today from Ray, Tony, Elizabeth, and Anita,
and I have been busy at NASA HQ talking about how to integrate VO efforts
with NASA's Planetary Data System.  I am following up on a more general
action to build relationships with related fields (including solar and space
physics).

NASA's PDS is also a distributed system, though much more top-down
controlled that the VO.  But they have had to solve very similar problems to
what we are dealing with, and I think it will be beneficial to share
technologies where appropriate.  We certainly want astronomers to be able to
locate data on planets, asteroids, and comets regardless of whether it is
obtained from ground-based telescopes or fly-by missions.

One of the topics we discussed was resource metadata and registries.  They
have followed an approach pioneered by ISAIA (Interoperable Systems for
Archival Information Access), a project that yours truly was the PI for, and
which included astronomy, planetary science, and space physics.  We used the
concept of "profiles", which in the VO context are the metadata relevant to
resources.  PDS stuck with the profile terminology, and have resource
profiles.  They are working on 'profiles of resource profiles' -- in other
words, registries.

The core of PDS's profile systems is, guess what... the Dublin Core.  And
this is with ~4 years of no real discussions between VO and planetary folks.
So, if we want to exchange resource-level metadata with our peers, I think
it is essential to stick with DC as far as we can.  This is not an abstract
Digital Libraries thing, this is about doing research in astronomy. So,
rant/end-rant aside, I believe that there is more to be gained by sticking
to DC where we can.  If DC is not clear at the user i/f level, we can fix
that through the i/f.  But we must transmit information on the wire using DC
where we can. We will do more and better astronomy if we stick with DC.

Tony suggested that some of the DC elements, like "publishers, contacts,
creators, and contributors" were not relevant for locating resources of
interest.  This is simply not true.  Astronomers always refer to catalogs by
their creators (where can I find the Burbidge & Burbidge catalog of quasars?
Where is the Dixon catalog of radio sources?).  They generally know who is
responsible for such catalogs or datasets (I think I remember seeing this at
NED, or at CDS), or remember who might have had something to do with it (I
remember something about a survey done at Palomor.. where can I find it
now?)  Astronomy is a small enough field that people know collections by
their creators, their publishers, and their contributors.  It is essential
to capture this information in the resource metadata.  It will be used all
the time.

There were some comments about the Date element.  RM metadata describes the
Resource, not the registry.  We must be absolutely consistent in this.  If
we want metadata to describe the latest date of revision of entries in the
registry, this is something separate from the latest date of revison of the
resource.  The curator may change, the ReferenceURL may change, but the
content represented by the Resource itself may not have changed.  Date
describes the Resource.  Things like DateEntered or DataRevised (please, not
DateUpdated!!) are about the registry.  They do not belong in RM at all.
They are meta-metadata.

Most of the other issues in today's e-mail are, I think, minor details.
This composition is becoming baroque, or even rococo, and the complexity is
overwhelming the structure.  We need to stop adding things, curliques upon
curliques, and get the pillars and beams up and see if they will withstand
the load.  Our fundamental building blocks are DC terms, to which we add the
pieces we need to accommodate our discipline.  If users cannot find the data
collections they want with our resource metadata, then we should augment
later.

Bob