Hi, answers below....
>> <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 agree, but it's nice to have it as an option (which as you pointed out it
already is) since in a very practical sense it is sometimes easier for
scripts and software which can deal with some aspects of SGML, but not well
with nesting and inheritence - I know, you don't design a DTD just for
current software, but in this case having both options might not be bad.
One could also use the PHYSFACET source attribute in cases where there were
only two PHYSFACETs, each having different sources I can imagine. (P.S.
museum finding aids might be more complex on the item level, but can be
easier in other ways, for instance we can usually get much of our item
level markup exported from a collection management system :)
>
>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
>
I wouldn't say it was "common" but I can see a use for it (though perhaps I
need to understand more about why empty tags would be bad). I could see
putting in some empty CONTROLACCESS tags just to insert normalized terms
from controlled vocabulary sources as access/search points in the document,
just in case these terms did not occur naturally in the document text. For
instance in my above example, if the artwork were referred to as a "bronze"
of St. Thomas, we all know that to mean a "bronze sculpture", but of course
software does not. So adding a controlled term "sculptures" from the AAT
would add that as an access point. Anyway, that's a use I can see, but I'm
still learning and happy to hear how it might be done better.
Thanks again for the feedback, I noticed that adding a "facettype" and
"type" attribute to PHYSFACET was included in the suggested DTD revisions
that was just sent out to this list - thanks!
Richard Rinehart | Berkeley Art Museum/Pacific Film Archive
Systems Manager & Education | University of California
Technology Specialist | 2625 Durant, Berkeley, CA 94720-2250
[log in to unmask] | http://www.bampfa.berkeley.edu/
& President-Elect, Museum Computer Network, http://www.mcn.edu/
|