As chair of the Date subgroup, it's safe to say there was significant
mis-communication in the position we were about to release and the
position that Stuart interpreted and posted (below).  This was probably
my fault and I'll try to correct it very soon.

In the mean time, I suggest that recipients of the these lists not put
particular store by the Date subelements as posted below.  The Date
subgroup is working with Stuart to clarify our intention.

-John

======== Date subgroup doesn't vouch for Date subelements below ========
From: "Weibel,Stu" <[log in to unmask]>
To: "[log in to unmask]" <[log in to unmask]>,
        "[log in to unmask]" <[log in to unmask]>
Cc: Stu Weibel <[log in to unmask]>
Subject: Subelements: URGENT ATTENTION REQUIRED
Date: Tue, 27 Jan 1998 15:20:16 -0500

Folks,

Due to the shortness of time, I am bringing some issues for finalization
to the entire list from some of the working group lists.  This message
has relevance for many of the WGs: 

  Subelements
  Date
  Relation, and 
  Coverage

Please note that it is not my intention to set aside the arduous work of
many in forging positions around these issues, but it is my strong
believe that for the purposes of the Finnish Finish, that the results of
these groups should be pared down to their simplest representations.

The special requirements that others have brought to the discussion must
find accomodation, but I think it is NOT in DC-Simple that these needs
should be met.  Remember, above all, we must have a succinct, coherent
message for would-be adopters:  a path forward for the adoption of
simple metadata that has as few ifs-ands-and-buts as possible, and an
evolutionary path for those with more complex objectives.

Thanks for looking closely at these.  I need to pin all this stuff down
by the end of this week so I can finish the report next week.

NOTE BENE:  If you wish to lodge support or criticism of some aspect of
this position, please address ONE TOPIC per message, and indicate the
topic clearly in the subject message.  I will be coordinating these
things on a very short time frame, and will miss important messages if
we're not careful about threading of messages.

let the slings and arrows begin

regards,

stu

--------text taken largely from Paul Miller's and John Kunze's working
groups -------------------------

A list of widely applicable subelements for the Dublin Core

Implementors are free to develop their own subelements in order to meet
specific local requirements. However, 
while application of numerous subelements to the Dublin Core is likely
to increase its value to any one application area or subject grouping,
the same action is equally likely to reduce the potential for
interoperability between domains. As such, the addition of subelements
to the 15 core elements of Dublin Core should be kept to a minimum and
should be used ONLY when there are compelling local reasons to support
such refinements.

It should also be emphasized that applications may simply collapse all
subelements into their parent element, and definition of subelements
should be deployed with this in mind.

Elements intended to extend the scope and functionality of Dublin Core
beyond the original 15 elements (rather than refining some aspect of the
existing elements) should adopt element-set extension strategies.  The
Resource Description Framework is evolving to meet these needs in the
Web, and several instances of such development are now evolving.

Nonetheless, early implementers have identified requirements for certain
key subelements. Rather than encourage proliferation of these common
subelements, with each application employing slightly different
nomenclature and semantics, some of the most commonly used subelements
are identified here and presented in a standardised form.  As can be
seen, most of the 15 elements remain unqualified.

The list of 'approved' subelements presented here does not in any way
exhaust the possibility of such elements, but every attempt will be made
to keep this list intuitive and succinct.  Note that applications
wishing to promulgate a formal set of additional elements can do so by
specifying a formal scheme enumerating such subelements.  Wide adoption
of a given scheme (or lack of adoption)is one mechanism for the
marketplace to signal desireable evolutionary paths for subelements,
either within bounded communities or more generally.

TITLE
 
  Title.Alternative

  Used for any titles other than the main title; including subtitle,
translated title, series title, vernacular name, etc.
 
 
CREATOR
 
  Creator.Name

  The name of a person or organization primarily responsible for
creating the intellexctual content of the resource.
 
  Creator.Address

  An electronic or physical address for the individual or oganization
specified in Creator.Name.  This could be an electronic mail address,
web page URL, postal address, etc., and might be further defined by use
of a SCHEME.
 
SUBJECT
 
  No SUBELEMENTs at present.
 
DESCRIPTION
 
  No SUBELEMENTs at present.
 
 
PUBLISHER
 
  Publisher.Name

  The name of a person or organization associated with the publication
of the resource.
  
  Publisher.Address

  An electronic or physical address for the individual in question. This
could be an electronic mail address, web page URL, postal address, etc.,
and is most useful if further defined by use of a SCHEME.
  
CONTRIBUTORS
 
Contributors.Name

The name of a person or organization (not specified in a Creator
element) who has made a contribution to the intellectual content of the
resource.
 
Contributors.Address

 An electronic or physical address for the person or organization in
question. This could be an electronic mail address, web page URL, postal
address, etc.,
and might be further defined by use of a SCHEME.
  
DATE

DC.Date.Created
 
  Date the resource was made available in its present form.  This is the
default notion of the DC.Date field.  It should only be qualified
further as DC.Date.Created when there are additional date subfields
specified.
 
DC.Date.Accepted
 
  Date of acceptance (e.g., for a dissertation, manuscript, or treaty)
of the resource.  The date assigned by a formal authority to signify
official acceptance.
 

DC.Date.Valid

  Valid entries here include a range of dates (start date and end date)
specifying a range of dates during which the information in the resource
is asserted to be valid.

DC.Date.ValidFrom

A single date entry specifying the first date on which the information
in the resource is asserted to be valid.

DC.Date.ValidUntil

  A single date entry specifying the last date on which the information
in the resource is asserted to be valid.


4.3.8  TYPE
 
 No SUBELEMENTs at present.
 
 
4.3.9  FORMAT
 
 No SUBELEMENTs at present.
 
 
4.3.10  IDENTIFIER
 
 No SUBELEMENTs at present.
 
 
4.3.11  SOURCE
 
 No SUBELEMENTs at present.
 
 4.3.12  LANGUAGE
 
 No SUBELEMENTs at present.
 
 
4.3.13  RELATION

The RELATION element logically requires three components: two entities
and a named relationship that links them.  The base entity is the
resource described by the metadata.  The target entity is separate
object that should be identified  in an unambiguous way with a globally
unique identifier (see the IDENTIFIER element).

Many communities have identified relationship hierarchies specific to
their fields of endeavor, and it is expected that scheme-qualified
relationship specifications will come to be used in domain specific
applications.  Unqualified relation specifications should chose from
among the following relation types for DC-Simple applications:

 
 Relation.IsPartOf [TARGET RESOURCE IDENTIFIER]

 The resource being described is physically and/or logically part of a
larger resource, referred to by this use of the element.
 
 Relation.HasPart [TARGET RESOURCE IDENTIFIER]

 The resource being described physically and/or logically contains one
or more constituent resources, referred to by this use of the element.
 
 Relation.IsVersionOf [TARGET RESOURCE IDENTIFIER]

 The resource being described is an historical state or edition of an
earlier resource by the same creator, the earliest instantiation of
which is referred to by this use of the element.
 
 Relation.HasVersion [TARGET RESOURCE IDENTIFIER]

 The resource being described is the earliest edition of a resource
later altered through further editions, one of which is referred to by
this use of the element.  As a practical matter, this will be unusual,
given that it would require updating of existing metadata, but automated
versioning systems might make good use of such a relation.
 
4.3.14  COVERAGE

For the purposes DC-Simple, the only practical solution appears to be
the inclusion of a place name or epoch (period) name selected from a
controlled vocabulary (a gazetteer, for example, of national or
international scope.  These are the most widely anticipated uses of such
an element for discovery.

It is recognized that many other means of specificaction of coverage are
possible (epoch names, geographical coordinate systems, polygonal
specifications, and others), but it is expected that these will be
outside the scope of common usage and should be elaborated as registered
schemes for the specific applications that grow around them.

 
Coverage.PeriodName

 The resource being described is from or related to a named historical
period, referred to by this use of the element.
 
Coverage.PlaceName

 The resource being described is associated with a named place,
identified by this use of the element.
  
 
4.3.15  RIGHTS
 
 No SUBELEMENTs at present.