Simon,
I think that the Source and Relatio elements are more properly referenced
withrespect to CONTENT than to INTELLECTUAL PROPERTY. Almost all the
discussion, and your subsequent definitions, suggest that the rationale for
these is to indicate the content of the resource by reference to its
relationship with another resource with which it shares some substantial
content.
David
At 03:27 PM 1/1/98 +0800, Simon Cox wrote:
>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/
>
>
>
David Bearman, President
Archives & Museum Informatics
5501 Walnut St., Suite 203
Pittsburgh, PA 15232 USA
ph. + 1-412-683-9775
fax + 1-412-683-7366
email: [log in to unmask]
URL: www.archimuse.com
|