Subject: [ESP] Dublin Core question

From: "Eric Marshall" <[email-masked]>
Date: Mon, 09 Jun 2003 15:48:56 -0400

What work has been done or discovered regarding how this community will 
want to standardize how folks will describe datasets in Dublin Core 
elements? I'm thinking of Type, 'a formal identification system' for 
Identifier, Relation (and aggregation) and what would be useful for 
Coverage and Format. Any thoughts?

        Regards,
		Eric Marshall

---

From: Luca Cinquini <[email-masked]>
Date: Mon, 09 Jun 2003 14:53:35 -0600

Hi Eric,
    here at NCAR we are actually experimenting with describing our high 
level search and discovery metadata in Dublin Core, since it was the 
only schema people could agree on - at least for the time being. It 
looks like the DC people finally agreed on an XML schema for encoding 
both unqualified and qualified Dublin Core elements, but as far as I 
understand there is yet no official recomendation for encoding the DCMI-Box
and DCMI-Period information (i.e. spatial coverage and temporal coverage 
respectively). Hopefully that will come soon.

In relation to your questions:

o for DCMI Type, we use the value "Collection" when writing metadata 
that describes a whole set of files
    (see definition at 
http://dublincore.org/documents/2003/03/04/dcmi-terms/)

o for identifier, we use a URI system based on a hierarchical relation 
between datasets: for example, "ucar.cgd.pcm.XX" is the root identifier for
all files produced by run XX of the model PCM, run by the CGD people at 
UCAR. A cross-institutional URI system could start with the name of the 
authority assigning the identifier, for example "esp:ucar.cgd.pcm.XX"

o Coverage we encode with the DCMI-Box and DCMI-Period, for example:
<dc:coverage>
<dcterms:spatial>
<box xmlns="http://dublincore.org/documents/2000/07/28/dcmi-box/"
name="the whole earth">
<northlimit>90</northlimit>
<eastlimit>0</eastlimit>
<southlimit>-90</southlimit>
<westlimit>360</westlimit>
</box>
</dcterms:spatial>
<dcterms:temporal>
<period xmlns="http://dublincore.org/documents/2000/07/28/dcmi-period/">
<start scheme="W3C-DTF">1983</start>
<end scheme="W3C-DTF">2000</end>
</period>
</dcterms:temporal>
</dc:coverage>
(even if, as I said, this is non-offical XML....)

o Relation-isPartOf could be used to express containment relationship 
between datasets, even if we haven't done so as yet.

o Format we simply use a free-form value, since for example "netcdf" is 
not listed in the recomended list of MIME types....

Let me just conclude by saying that it would be great if this group 
would come up with a joint recomandation on how to use DC for high-level 
description of scientific data....

thanks, Luca

Eric Marshall wrote:

> What work has been done or discovered regarding how this community 
> will want to standardize how folks will describe datasets in Dublin 
> Core elements? I'm thinking of Type, 'a formal identification system' 
> for Identifier, Relation (and aggregation) and what would be useful 
> for Coverage and Format. Any thoughts?
>
>        Regards,
>         Eric Marshall
>
> _______________________________________________
> ESP mailing list
> [email-masked]
> http://mailman.ucar.edu/mailman/listinfo/esp

---

From: Ethan Davis <[email-masked]>
Date: Mon, 09 Jun 2003 15:56:44 -0600

Hi Eric, Luca,

One problem we've run into with DCMI-Period and most other time encoding schemes
is the lack of relative times. We deal with a lot of real-time data and have
archives that cover a certain number of days back from present. This kind of
thing is hard to represent in most time encoding schemes. The only metadata
encoding I'm aware of that deals with relative time is ADN (see below) which has
a timePast element.

Just a heads-up for anyone dealing with real-time data.

Ethan

(+) ADN is a metadata scheme developed by people at the Alexandria Digital
Library, DLESE (Digital Library for Earth Science Education, and NASA.
http://www.dlese.org/Metadata/adn-collaboration/

-- 
Ethan R. Davis                       Telephone: (303) 497-8155
Software Engineer                    Fax:       (303) 497-8690
UCAR Unidata Program Center          E-mail:    [email-masked]
P.O. Box 3000
Boulder, CO  80307-3000              http://www.unidata.ucar.edu/