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
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."
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
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.
SGML Project Specialist
Dance Heritage Coalition