On Mon, 2 Dec 1996, Stu Weibel wrote:
> 	  Dublin Core Metadata Element Set: Reference Description
> Element Descriptions 
> [...]
>    * CREATOR
> 
>      The person(s) 

...and/or organisation(s)...

>                    primarily responsible for the intellectual content
>      of the object.  For example, authors in the case of written documents,
>      artists, photographers, or illustrators in the the case of visual
>      resources.

I can see why Author might not be appropriate for non-textual material but
will people attaching metadata be looking for an Author element?  I don't
know.  Personally I'm not too worried about this as either Author or
Creator seem reasonable to me.  We just need to agree on one once and for
all and *_then_stick_to_it_*. 
 
>    * DESCRIPTION
>  
>      The topic of the work, or keywords that describe the subject or
>      content of the resource, whether text-based or visual.

I still prefered Subject myself; Description doesn't really convey things
like LCSH and MeSH terms that might appear in this Element.

[...]
 
>    * OTHER AGENT (CONTRIBUTOR?)
> 
>      The person(s) 

...and/or organisation(s)...

>                    other than author(s)

Maybe "creator(s)" if we do rename the author element?  And don't forget
it excludes the publisher(s) as well. 

>                                         who have made significant
>      intellectual contributions to the resource but whose contribution is
>      secondary to the individuals

... and/or organisations...

>                                    specifed in the CREATOR field (for
>      example, editors, transcribers, illustrators, convenors).
> 
>    * DATE
> 
>      The date the resource was made available in its present form.  [If possible,
>      a default format of wide international acceptance should be specified
>      here.  Any suggestions?]

Well, I've had five ideas/suggestions from people for schemes for my
qualifiers list for this element so far: 

 * IETF.RFC-822 
      Date conforms to the date formats described in RFC 822, for
      example "Sat, 31 Aug 1996 21:12:34 +0100".
 * ISO.31-1:1992 
      Date conforms to the date formats described in ISO 31-1:1992. For
      example 1996-08-31. 
 * ANSI.X3.30-1985 
      Date conforms to the date formats described in ANSI X3.30-1985. 
 * FGDC 
      Date conforms to the date formats described in the FGDC. For
      example 19960831. 
 * SSE 
      Seconds Since the Epoch; the standard UNIX internal time keeping
      format. This is an integer number of seconds since midnight on 1st
      January 1970. 

For want of any existing consensus (or even discussion unless I missed it) 
I plumped for the RFC-822 format as the default as its fairly widely
deployed and we know it works (millions of email messages can't be
wrong...).  Does this seem reasonable to everyone else?  Are there other
major formats that I've missed?

>    * RESOURCE TYPE [used to be TYPE]

Er, don't you mean that this used to be ObjectType (see
<URL:http://purl.org/metadata/dublin_core_elements>)?

>      The genre of the resource, such as home page, novel, poem, working
>      paper, technical report, essay, dictionary, etc.  It is expected that
>      RESOURCE TYPE will be chosen from an enumerated list of types. 

OK, I'll go along with the consensus on the naming of this one.  My
contribution to the consensus building on the enumerated list of genres is
available at
<URL:http://www.roads.lut.ac.uk/Metadata/DC-ObjectTypes.html>; these were
based on BibTex genre types plus some additions from other DCers. 
 
>    * FORMAT [used to be FORM]
> 
>      The data representation of the object, such as text/html, ASCII,
>      Postscript file, Windows executable file, JPEG image, etc.  The
>      intent of this element is to provide information necessary to
>      allow people or machines to make decisions about the usability of
>      the encoded data (what hardware and software might be required to
>      display it, for example).  As with RESOURCE TYPE, FORMAT will be
>      assigned from enumerated lists sucha s registered Internet Media
>      Types (MIME types).

Fine again.
       
> 
>    * RIGHTS MANAGEMENT [need a snappy, single word element name here]

Alright, how about "RightsManagement". :-) :-)  Seriously, I think Rights
Management (with or without the space) is fine as it does actually
describe what is expected for the field (unless someone wants to make it
"Resource Rights Management" in case people confuse it with a statement of
access rights on the metadata itself.... joke folks, joke :-) ).
 
Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *