Many thanks, everyone, for these replies. It's very helpful to have these perspectives. Maybe if ISAD (G) doesn't distinguish one type of note from the other, we shouldn't either.
Thanks again!
Marsha Maguire
Manuscripts & Special Collections
Cataloging Librarian
University of Washington Libraries
P.O. Box 352900
Seattle, WA 98195
(206) 543-8407
[log in to unmask]
On Wed, 1 Oct 2003, Fox, Michael wrote:
> To reiterate, I did say that I thought adding a type attribute had merit.
>
> Our use a the Minnesota Historical Society of the altrender attribute is
> certainly a stretch, though arguably less a stretch in our case as it
> controls how an icon, or rather which icon, is rendered rather than
> supplying text. But a minor hack nevertheless.
>
> As to the use of encodinganalog, having a stylesheet discern between "545 1"
> and "545 0" puts an awful premium on string pattern matching, especially
> since there is no standard (except in the RLG guidelines) as to how the
> values are represented in the attribute. Is "$545 0" or "545 0"? Lots of
> opportunities for typographical errors.
>
> To say that <head> elements are not required is true but not particularly
> useful. Almost nothing is required by the DTD. EAD is not a data content
> standard and is not in the business of prescribing or enforcing the content
> or even presence of particular elements. With two or three exceptions, the
> required elements all have to do with the identification of the electronic
> file.
>
> Even if one had a type attribute, it would be outside the domain of EAD to
> define the relevant values if for no other reason than that the terms might
> be different in different countries. The need to make EAD even more
> internationally useful in this way was one of the reasons behind removing
> many of the prescribed lists of values for attributes in version 1.0. Even
> more so because, as is pointed out, ISAD(G) does not make a distinction.
>
> Michael
>
>
>
>
> -----Original Message-----
> From: M. Carlson [mailto:[log in to unmask]]
> Sent: Wednesday, October 01, 2003 10:25 AM
> To: [log in to unmask]
> Subject: Re: Question about <bioghist>
>
>
> On Tue, 30 Sep 2003, Fox, Michael wrote:
>
> > The Minnesota Historical Society uses the altrender attribute in a
> somewhat
> > similar way. The text of our "table of contents" consists of a series of
> > icons rather than the text taken directly from <head> elements. While we
> do
> > include <head> elements in the body of the finding aid, we use a value in
> > @altrender to determine whether the icon that reads "Administrative
> History"
> > or the one that says "Biography" appears.
> >
> > That said, Marsha's suggestion for a type attribute has merit.
> >
> > On the other hand, I am not sure that personally agree that all this
> display
> > information should always be left to the stylesheet. I think that it is
> > probably useful to include heads and labels, if only as a default when
> > finding aids leave the creating institution or consortium and go off to
> who
> > knows where to be interpreted by a stylesheet that may assume their
> > presence.
> >
> > Michael
>
>
> But since <head> elements are not *required* elements, that seems to imply
> that a style sheet should at least provide a "default" on its own without
> "assuming" anything and that "tests" should be performed on whether a
> particular combination of parent/child elements exist, not on whether a
> <head> element exists among those parent/child elements.
>
> The benefit of having a "type" attribute would be that some consistency in
> encoding it could be suggested among repositories who want to distinguish
> between different types of <bioghist> notes. This is best handled by an
> attribute (consistently applied among repositories) rather than a value in
> a <head> element which will vary (or perhaps omitted) among those
> repositories.
>
> I don't think any such consistency could be imposed on an attribute such
> as 'altrender'. According to the tag library, the attribute's definition
> is:
>
> "The content of the element should be displayed or printed differently
> than the rendering established in a style sheet for other occurrences of
> the element"
>
> In this case, it's not so much to print a different heading (although that
> may be a result) but to indicate the type of data that <bioghist>
> contains.
>
|