New XML Schema for Resource Metadata

[Robert Hanisch]

Sorry to be so slow in commenting -- vacations, NVO team meeting, and other
things have gotten in the way!

Under Major Changes, we have

a..
  1.. In previous versions, it was unclear why certain terms were attributes
of a resource's Curation and other, its Content. Furthermore, it was unclear
what was considered the "content" of a resource like Organisation.
  2.. To clarify this distinction, the term Subject replaces Content,
refering to the focus of a resource; the sub-elements describe various
aspects of that focus. The term previously refered to as Subject is now
called Topic.
I had to talk with Ray to understand the need for these changes, and in the
end think we are better off the previous way.

First, the DC definition of Subject is "A list of the topics, object types,
or other descriptive keywords about the resource."  So Subject encompasses
"topic" already, and to use one term instead of the other seems to me to
just be going around in circles.  Topic comes into the picture because
ContentLevel, Facility, and Instrument are all grouped under Subject.  I
think this is an organizational mistake.  Facility and Instrument do not fit
into the DC definition above.  The HST Data Archive is not "about" HST or
WFPC2.  HST and WFPC2 are used to acquire the data.  You will not find much
information about HST or WFPC2 in the data archive.  You will find data
about quasars, AGN, globular clusters, planets, etc.  Those are the
Subjects.  The goal of calibration is to remove instrumental signatures as
much as possible.  High-level resources (catalog compilations) can be based
on observations from many telescopes and many instruments, and they are
assuredly not "about" these instruments, but rather about CVs, QSOs, or
whatever.

If Facility, Instrument, and ContentLevel are moved out from under Subject,
there is no need for adding Topic.  As constructed now it just delimits the
elements in the Subject list.  How to encode lists has been discussed
extensively already, and does not require introduction of a new metadata
element.

I think ContentLevel belongs with Description and Type.  Type and
ContentLevel, in particular, are metadata elements that allow consumers to
filter out resources independent of Subject.

RM0.8 does not actually include a plain Content element, only ContentLevel.
I don't see Content in any of the data model structure diagrams.  Do we need
a generic Content in RM?

I also do not really see a need to introduce the Manager element.  Publisher
is defined as "An entity responsible for making the resource available," and
thus has a broader purview than, say, the publisher of a book.  A resource
describing an Organization can still have a Publisher, i.e., the person
responsible for the resource metadata description of the organization.  This
seems clear enough, and introduction of Manager would seem to only add the
potential for confusion.  Indeed, the Manager of a resource may not be the
Publisher, but it is the latter concept that is important for the registry.

I hope to reconcile this nice work by Ray and Tony with RM so that we have a
consistent set of specifications to go forward with from ADASS.

Cheers,

Bob


----- Original Message ----- 
From: "Ray Plante" <rplante at poplar.ncsa.uiuc.edu>
To: <registry at ivoa.net>
Sent: Tuesday, September 09, 2003 7:26 AM
Subject: New XML Schema for Resource Metadata


> Hi all,
>
> As you may know, Tony and I took some time to examine and revise the
> structure of the resource metadata, and the results are now posted on the
> IVOARegWp03 page.  We would like to get your feedback with the goal of
> settling by the end of the month on a base schema for use in IVOA registry
> demos.
>
> You can access the schemas from
>
http://www.ivoa.net/internal/IVOA/IVOARegWp03/VOResource-v0.8.1-overview.html
> along with a sample instance document.  You will notice that the metadata
> are divided between a core schema and a few extensions.  The document
> above also enumerates the major issues this latest version attempts to
> address.  Comments on that front are especially helpful.
>
> Over the next few days, I'll add additional examples to further illustrate
> the use of the metadata.  Your comments can be sent to this registry list.
>
> thanks!
> Ray
>
>
>