Print

Print


     It seems to us that there are several issues at stake in the
     discussion of  <did> which need to be teased apart in order to come to
     any conclusions.  Here are our reading of, and opinions on, the
     issues:

     1) The <did> definition

     The definition of <did> as "identifying fundamental descriptive
     information needed to  identify the component" makes assumptions about
     what is "fundamental" and "needed to identify," but does not explain
     the rationale for those assumptions.  The implication is that  the
     <did> tag is intended to dictate or require what "fundamental"
     information is needed to identify a component or unit.  However, as it
     stands now, the information permitted in <did> is not required,
     indicating it is not "fundamental" but rather "desired."

     2) <scopecontent>
     As the definition of the <did> stands, the debate rests on determining
     if <scopecontent> is fundamental identifying information.  There seems
     to be the feeling that because it is a summary, it is too general to
     be used as an identifier.  This, however, is dependent on the
     use of <scopecontent> and, since there is not a standard for the
     content of the tag, the use will vary.   Since <scopecontent> pertains
     to a specific component and may contain detailed information about its
     contents, it seems as if it could act and frequently does act
     in an identifying capacity.

     We would prefer not to put information about the contents of the
     component in <note> within <did>.   Because <note> seems to be such a
     broadly-defined tag, with so many possible applications, we start to
     lose the control over data, the very control that is the reason we are
     marking up the finding aids.  We use <note>  elsewhere in <c> for
     different kinds of information, such as location of research copies.
     If <did> can include <note>, further, its seems it could also
     accommodate <scopecontent>, which, as we read it, has a more specific
     purpose in describing or identifying the information component than
     <note>.

     3) <physdesc> and <scopecontent>
     - The discussion of <scopecontent> within <did> raises the matter of
     overlap between <physdesc> and <scopecontent>.  Often information
     coded within <scopecontent> includes physical description.  In the
     example cited by Leslie Morris, for instance, "newsclippings and
     photographs" is in <scopecontent>, but could also be in <physdesc>.

     Frequently information regarding physical description will have been
     written into <scopecontent>.  Because of this overlap, it seems
     logical that if  <physdesc> is allowed within <did> then
     <scopecontent> might also be appropriate.

     4) Identification v. Summary

     The debate between the <did> defined role as fundamental identifying
     information and its potential role as summary overview may not be as
     far apart as the discussion suggests.  In both cases, the <did> exists
     to provide information about a specific component or unit. If
     <scopecontent> were allowed within the <did> all the information
     within the <did> would still serve to identify the component, but
     would simply offer more description.

     It seems, again, that the problem stems from the difficulty in
     defining "needed" and "fundamental."  Perhaps, as others have
     suggested, the solution lies in changing the definition of <did> so it
     can accommodate these two relatively similar roles.

     5) Is <did> necessary
     Kris Kiesling has suggested making <did> optional.  We, at least,
     would like to continue to bundle the descriptive elements together, as
     it helps organize the information.   This desire to keep the
     descriptive information together, in fact, leads us to believe
     <scopecontent> should be within <did>; otherwise this important
     description floats between <did> and the next component level.


     Catherine Johnson
     Project Director

     Kate Culkin
     SGML Project Specialist

     Dance Heritage Coalition