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