 |
 |
Simon, Sorry for the delay. I'll respond to some of your suggestions here and then post the revised basic elements draft RFC. > Date: Thu, 01 Jan 1998 15:27:31 +0800 > From: Simon Cox <[log in to unmask]> > > 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> OK, I've added a statement about order insensitivity, but avoided the controversial term "metadata set", which was already used earlier in the document (in "... Dublin Core Meadata Element Set"). > <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> ... Sounds good. > (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 ... OK. Until I hear otherwise, I'll do this with a minor variation: your [final] grouping will be summarized in front of the element descriptions, and then the elements will be put in alphabetical order by element "label". The result includes thus the grouping plus a scannable description list suitable for quick lookup. On the down side, some obscure elements appear first (though this still seems preferable to me than the almost arbitrary order they were in before). > 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", Again, I'd rather not use "set" (means too many different closely related things, eg, Z39.50 "Dublin Core attribute set"). We should get a definition for some kind of "metadata record", but we can sidestep it for now. > and have used the term "_present_ resource" where I think it clarifies. Yes, that's better than "this resource". I also added note in the beginning to counter any perceived bias against non-embedded metadata. > 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? I thought it was more suitable under Source, because that's the exception that proves the rule. > 2. The "Source/Relation" thing. I suggest rewording: I've liberally adapted your wording changes in the revision that I'll post next. Thanks for all the suggestions. -John