Stu

short reply only.  More to come once I've had a chance to catch up on
the  email on the meta2 list.  My comments are biased towards metadata
presentation to searchers in what John K. refers to as the search phase of
the request/response search cycle.  The DC has several audiences but in
the end, the searchers, in my opinion, are the primary audience (even if
only by a whisker).  

If the DC is only aimed at metadata provision I don't believe naming needs
to be intuitive - it helps, but it isn't necessary as long as there is
common agreement on definitions and
scope of the element (and the names don't keep changing).  I'm making
assumptions here about the sorts of people who are going to be providing
metadata in that they will have the intellectual capacity to understand
that naming objects is arbitrary - you know, the sorts of people who have
at least one complex metadata scheme under their belt, or are sophisticated
users of a range of systems supporting variant metadata models.

  As I see it an indexer also  has the option to present
any names it chooses against an element - that is, translating 
elements to attributes in an application isn't anything new (or it
shouldn't be anyway)

However, by establishing DC best practice (scope, naming, definition, and
syntax), there is the hope that the metadata presented on search engines
should be accessible to most - (I'd like to say all but I'm a realist)


The following are some suggestions on naming.  


* I really believe "SUBJECT" is more intuitive than "Description",

* Prefer "CONTRIBUTOR" over "OTHER AGENT" 

* IDENTIFIER is o.k. on the less is more theory (personal preference is
for RESOURCE IDENTIFIER but I'll live)

* Alternatives to RIGHTS MANAGEMENT - how about "AVAILABILITY" (too
vague) or "USAGE" or "CONDITIONS"


Bemal

On Mon, 2 Dec 1996, Stu Weibel wrote:

> 
> The first and overarching goal of this group is to identify as best we
> can a commonly understood semantics for DC metadata.  We are close to
> that.  We will never, as Leslie suggests, achieve the holy grail.
> 
> The second important goal is to agree on the carrier syntax for the
> semantic content.  These two goals are, I think, getting a bit
> tangled.  This is probably inevititable, but I'd like to try to step
> back briefly and make sure we have consensus on the elements and their
> names before we try and untangle the knotier problems.
> 
> The attached is a revision of the reference element description.
> Please look at it and tell me where I'm off in the weeds.  You're
> welcome to suggest element name changes (or criticize mine), but I
> think no changes should be made unless there is overwhelmingly reason
> to do so.
> -------------------------------------------------------------------------
> 
> 	  Dublin Core Metadata Element Set: Reference Description
>  
> Element Descriptions 
> 
>    * TITLE
> 
>      The name given to the work by the creator or publisher.
> 
>    * CREATOR
> 
>      The person(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.
> 
>    * DESCRIPTION
>  
>      The topic of the work, or keywords that describe the subject or
>      content of the resource, whether text-based or visual.
>           
>    * PUBLISHER
> 
>      The organization responsible for making the resource available in its
>      present form. Generally a publisher, an institution (university
>      department, for example) or a corporate entity.   The intent of this field 
>      is to identify organizations that fulfill a publishing role, rather than
>      individuals that simply provide informal access to a resource. 
> 
>    * OTHER AGENT (CONTRIBUTOR?)
> 
>      The person(s) other than author(s) who have made significant
>      intellectual contributions to the resource but whose contribution is
>      secondary to the individuals 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?]
> 
>    * RESOURCE TYPE [used to be TYPE]
> 
>      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. 
> 
>    * 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).
> 
>       
>    * IDENTIFIER (RESOURCE IDENTIFIER?)
> 
>      String or number used to uniquely identify the object. Examples
>      for networked resources include URLs, URNs (when implemented). For
>      non-networked objects, one might have an ISBN, Library of Congress
>      Catalog Number, or other formal name.
> 
>    * SOURCE
> 
>      Object, either print or electronic, from which this object is
>      derived, if applicable. For example, an html encoding of a
>      Shakespearean sonnet might identify the paper version of the
>      sonnet from which the electronic version was transcribed.
> 
>    * LANGUAGE 
> 
>      Language of the intellectual content of the resource.  The default
>      expression of natural languages is according to the ISO 639 two
>      letter language codes.  
>      
>      See:
>      
>      http://www.stonehand.com/unicode/standard/iso639.html.
> 
>    * RELATION 
> 
>      Relationship to other resources.  The intent is to provide a means
>      to express relationships among resources that have formal
>      relationships to other objects but exist as discrete resources
>      themselves.  For example, images in a document,  chapters in a
>      book, items in a collection.  A formal specification of RELATION is
>      currently under development.  Users and developers should
>      understand that use of this element should be currently considered
>      experimental.
> 
>    * COVERAGE
> 
>      The spatial locations and temporal durations characteristic of the
>      resource.    Formal specification of COVERAGE is currently under
>      development. Users and developers should understand that use of
>      this element should be currently considered experimental.
> 
>    * RIGHTS MANAGEMENT [need a snappy, single word element name here]
> 
>      The contents of this field is intended to be a pointer (a URL or
>      other suitable URI as appropriate) to a rights management
>      statement or a server that would provide such information in a
>      dynamic way.  The intent of this field is to allow providers a
>      means to associate terms and conditions or copyright statements
>      with a resource or collection of resources.   No assumptions
>      should be made by users if such a field is empty or not present.



==============================================================================
Bemal Rajapatirana
Database Team
NDIS Project Office				Email: [log in to unmask]
National Library of Australia			Phone: 61 6 262 1205
Canberra ACT 2600 AUSTRALIA			Fax  : 61 6 273 2116

The National Document & Information Service is a joint project of the 
National Library of Australia and the National Library of New Zealand.

==============================================================================