On Fri, 3 Oct 1997, Tim Hutchinson wrote:
> Further to my postings of a few days ago, I am wondering what the
> possibilities are for creating indexes of subjects, names of
> creators, and subjects, at the same time keeping track of which
> names are subject access points and which names are provenance
> access points. One way that occurs to me is using ENCODINGANALOG, e.g.
>
> <CONTROLACCESS>
> <CORPNAME ENCODINGANALOG="610"> subject
> <CORPNAME ENCODINGANALOG="710"> provenance
>
> My question, then, is: can ENCODINGANALOG (and indeed attributes in
> general) be used to create indexes? (e.g. of all provenance access points
> regardless of whether it's a persname, corpname or famname)?. Does one
> need a fancier search engine to perform such tasks?
Tim's suggested use of the "encodinganalog" attribute on controlled
vocabulary terms seems like a good solution for being able to process on
the reason for the controlled access: is something a contributor (I think
we meant the same thing in the Bentley finding aids as Tim means by his
use of the term "provenance" here), subject or form/genre?
My only experience, and an indirect one at that, has been with OpenText's
PAT search engine. The wizard SGML programmer Nigel Kerr at Univ. of
Michigan was able to make clever usages of attribute values in the scripts
he wrote to process EAD-encoded data using PAT. One could certainly also
construct search input forms for either the casual user or the archivist
that took advantage of the attribute values of certain tags in order to
refine queries of the EAD-encoded finding aids.
One caveat about this clever usage of attribute values in search scripts
though: it places much heavier emphasis on standardization of data input
(if you tag something as a <c03 level="file"> in one place and plan to
process on that attribute, all other <c03>s that are files need to be so
labelled). Before "announcing" the Michigan/Bentley EAD interface to
this list and after Nigel had called our attention to display problems due
solely to attribute inconsistencies, Greg Kinney and I spent two lengthy
nights reviewing the files for about 30 finding aids and correcting those
inconsistencies so that the display of the finding aids in the system
worked as intended. Part of the reason for the problem was that the
finding aids had been tagged at various times over a few month period as
our understanding and use of the DTD developed. But I could've sworn that
I had already cleaned up all the attribute inconsistencies. Leave it to
the programmer to show you just how wrong you are about data consistency
;-)
________ [Bill Landis] ___________________________ [[log in to unmask]]
Graduate School of Education & Information Studies
University of California, Los Angeles
