John - I think you are the "keeper" of the draft RFC.  
Following recent discussion on meta2, and in the spirit 
of Stu's admonition to instantiate suggested improvements, 
may I offer the following:  

1.  the sequence/ordering thing:  

(a) In Section 3. of the RFC, make the following changes 
starting at the last sentence of para 2:  
 
...<DEL>Further note that each element is optional and
repeatable.</DEL></P> 

<INS><P>Each element is optional and repeatable.  
        No significance is to be attached or conveyed by the 
        order in which the elements are presented, stored or 
        transmited within a metadata set.  </P>

     <P>The element descriptions below are presented in three 
	groups which indicate the general class or scope of 
	the information stored in the metadata elements.  </INS>
   <DEL>In the element descriptions below, a</DEL><INS>A</INS> ...


(b) I'm not sure what the best strategy for reorganising 
the sub-headings, etc is.  The three groups (Content, IP, 
Instantiation) might merit three level 2 subheads 3.1, 3.2, 
3.3, but this would then drive the elements themselves down 
to level 3 (3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.1, etc) 
which slightly undermines the idea that we have one set of 15, 
rather than three sets of five, six and four.  Would it be 
possible to insert separators in the RFC which are _not_ 
numbered sub-heads?  or could the content/IP/instantiation 
class membership be indicated in some other way?  I kinda 
like the phrase "Elements related mainly to the 
Content/IP/Instantiation of the resource", which 
looks more like a heading than a class label ...

Whatever, I repeat my suggested improved sequence for 
the element descriptions: 

   Elements related mainly to the CONTENT of the resource
        Title
        Subject
        Description
        Language
        Coverage

   Elements related mainly to INTELLECTUAL PROPERTY of the resource
        Creator
        Contributors
        Publisher
        Rights
        Source
        Relation

   Elements related mainly to the INSTANTIATION of the resource
        Identifier
        Format
        Type
        Date

2.  The "Source/Relation" thing.  I suggest rewording:   

3.10 (???) Source			Label:"Source"

     Information about a second resource from which the present 
     resource is derived.  This element will normally 
     contain information which properly belongs in the metadata 
     set for the second resource, but may be included in this  
     element of the metadata for the present resource 
     if it is likely to be important for discovery of the present 
     resource.  This element will not be applicable for a resource 
     that appears in its original form.  Note that the "Relation" 
     element would normally be used to indicate the identity of 
     related resources, including immediate ancestors.  
     [In some cases this would allow separate retrieval of the 
     complete metadata set for the related resource.- optional?]  

3.11 (???) Relation                     Label: "Relation"

     An identifier of a second resource and its relationship to the 
     present resource.  This element permits links between related 
     resources to be indicated.  Examples include a translation of 
     a work, chapters of a book, or a mechanical transformation of 
     a data-set into an image.  Relationships should be selected
     from an enumerated list that is currently under developments.  
     Note that in general the DC metadata elements will contain 
     information about a resource in its present instantiation only.  
     Indication of a "Relation" allows location of related 
     resources, including ancestors, and retrieval of the separate 
     metadata sets for these where they exist.  
     [If it considered essential for resource discovery purposes 
     to embed descriptive information about a second resource in 
     the metadata for the present resource, then the "Source" 
     element should be used. - optional?]  

I've tried to make the contrast between Source and Relation 
quite explicit here through some cross-referencing.  
I've also been careful to use the term "set" rather than "package", 
and have used the term "_present_ resource" where I think it clarifies.  
If you look carefully, you'll also see that I've embedded a statement 
of the 1:1 principle in the last paragraph.  Should this be made 
more grandly somewhere else in the RFC?  
-- 
__________________________________________________
Dr Simon Cox - Australian Geodynamics Cooperative Research Centre
CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia
T:  +61 8 9389 8421   F:  +61 8 9389 1906   [log in to unmask]
http://www.ned.dem.csiro.au/SimonCox/