On Thu, 23 Oct 1997, Richard Rinehart wrote:

>
> <CONTROLACCESS><GENREFORM SOURCE="AAT"
> NORMAL="sculptures"></GENREFORM></CONTROLACCESS> ...
>
> <PHYSDESC source="othersource" othersource="CDWA">
> <PHYSFACET label="materials-description"> bronze </PHYSFACET>
> <PHYSFACET label="materials-processes"> hollow sand-casting </PHYSFACET>
> <PHYSFACET label="measurements-dimensions"><DIMENSIONS>199 w x 400 h
> centimeters</DIMENSIONS></PHYSFACET>
> <PHYSFACET label="measurements-extent"> including bronze cast, but not
> marble base, measured at tallest and widest points </PHYSFACET>
> </PHYSDESC>

Thanks, Richard, for a great example that makes me glad I'm not creating
encoded finding aids for museum objects!  As you point out, you could do
the source attribute either in <physdesc> as above, or in all of the
<physfacet>s, though the latter would certainly not be taking advantage of
the hierarchical nesting capabilities of SGML and, IMHO, should be
discouraged as a tagging practice.

I have one more question about the first part of your example, again due
mainly to my ignorance of the data you're encoding.

> <CONTROLACCESS><GENREFORM SOURCE="AAT"
> NORMAL="sculptures"></GENREFORM></CONTROLACCESS> ...

Would this <controlaccess> tag group really be empty? and if so, what
purpose would that serve?  It seems to me that apart from blatantly
procedural tags like <lb>, encoding with empty tags is a bad idea and
suggests (to me at least) a "work-around" that should perhaps be addressed
some other way in the DTD.  So I guess I'm just asking if tagging like the
<controlaccess> group above would be a regular occurence in the kinds of
finding aids you work with?

Thanks again for your explanation!

Bill

________ [Bill Landis] ___________________________ [[log in to unmask]]
      Graduate School of Education & Information Studies
   University of California, Los Angeles