Schema 0.8.3

[Tony Linde]

Hi Bob,

I've been trying to find where PDS uses DC. Do you have any references? The
only stuff I can find seems to represent metadata as keyword=value pairs,
eg:

 
http://pdssbn.astro.umd.edu/SBNcgi/pds_display?archive=SBNast&directory=arch
ive/LC&filename=lc.lbl

or

 
http://pdssbn.astro.umd.edu/SBNcgi/pds_display?archive=SBNast&directory=arch
ive/NEARMOD/data/msi&filename=253mathimg.lbl

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
>