Schema 0.8.3

[Tony Linde]

Hi Bob,

> 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.

As I've tried to get across, I am perfectly happy for us to 'transmit
information on the wire using DC' (I assume this means providing an OAI
compliant harvesting interface). But this really does not mean having to use
DC names anywhere in the schema. If the name means the same in both fields
then let's use it but if not, we can use the astronomy term in our schemas
and translate to DC term at the harvesting interface. The translation will
happen anyway whether the names are the same or not so why not use astronomy
terms.

> 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 

I stand corrected - my expertise is systems building, not astronomy.

> minor details. This composition is becoming baroque, or even 
> rococo, and the complexity is overwhelming the structure.  We 

Quite the opposite. From a software point of view a single monolithic schema
is incredibly complex - so many decisions have to be hard coded into the
software - systems built on such a schema simply won't work together. A
structured schema in which most decisions are encoded into the schema makes
the software much simpler and interoperability easier to ensure.

> There were some comments about the Date element.  RM metadata 
> describes the Resource, not the registry.  We must be 

Again, if it is needed for astro info then fine. I find the name 'Date'
extremely uninformative though.

I'm happy for the RM document to exclude meta-metadata but it ought to be in
the schema for registry interop reasons.

> load.  Our fundamental building blocks are DC terms, to which 
> we add the pieces we need to accommodate our discipline.  If 

The 'Dublin Core metadata element set is a standard for cross-domain
information resource description' (http://dublincore.org/documents/dces/)
but for resource description *within* astronomy we should use relevant terms
and structures. DC compliance for cross-domain purposes is *easy* to add on.

Cheers,
Tony. 

> -----Original Message-----
> From: Robert Hanisch [mailto:rjhanisch at worldnet.att.net] 
> Sent: 02 October 2003 03:05
> To: Tony Linde; 'Ray Plante'
> Cc: registry at ivoa.net
> Subject: Re: Schema 0.8.3
> 
> 
> 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
>