Grant B.,
I recently went to the XML Conference here in Washington, DC.
What was well articulated was something I have been implementing.
I believe the answer is in doing away with the single publishing
event workflow. The front-end and back-end of database management is
a good start to re-designing the whole data collection process.
In the workflow I have created, there are a number of source
documents that interact with the stylesheet to produce the EAD XML
(and any ent documents as well).
Data collection remains the same. Data can be brought in from a
database or a word processor document. I have on occasion cleaned up
old database files and re-created the database from the cleaned up
XML document. The data collector can then start with a clean version
of the database (and that goes as well for character issues). Word
processor documents become master XML documents. Updates and changes
are submitted either in word processor formats or in edited hard
copy.
With various source documents used in the creation of the final EAD
XML document, I believe that it is possible to have the best of both
worlds.
Creating workflows that avoid the single publishing event seem to me
to be the answer.
Mike Ferrando
Library Technician
Music Division
Library of Congress
Washington, DC
202-707-4454
--- "Grant E. L. Buttars" <[log in to unmask]> wrote:
> The issue of database(s) vs static xml markup is something we are
> beginning to address here too. As the amount of ead encoded data
> grows
> we are finding it overly complex to istigate global changes across
> multiple xml documents and larger catalogues are beginning to make
> certain computers groan under the strain.
>
> I have been ivestigating ead/xml output from an SQL database and it
> functions very well at a basic level. I can get fully functional
> ead
> with relatively basic php scripts.
>
> However I share the misgivings that have been put forward in
> relation to
> more complex tagging e.g. <bibref> within <p> within <scopecontent>
> which don't occur in the same controlled manner as other tags.
> Similarly <date> or <dao>. Without these the richness in
> functionality
> is lost.
>
> What would interest me is a hybrid of some sort, where the best of
> both
> systems can be used, pulling in external controlled data from a
> database
> and allowing a cental point of editing for recurring data (e.g.
> repository name & address, <controlaccess> terms etc.), but where
> the
> core catalogue data remained in a static xml document. Has anyone
> investigated this at all?
>
> ---------------------------------
> Grant E. L. Buttars
> Deputy University Archivist
> Special Collections
> Edinburgh University Library
> George Square
> Edinburgh
> EH8 9LJ
> http://www.lib.ed.ac.uk/speccoll/eua/
> tel: 0131 651 3852
>
> > -----Original Message-----
> > From: Encoded Archival Description List [mailto:[log in to unmask]]
> > On Behalf Of Mike Ferrando
> > Sent: 22 December 2004 14:01
> > To: [log in to unmask]
> > Subject: Re: MYSQL and EAD
> >
> >
> > Friends,
> > One thing that really troubles me about the database approach
> > is the attributes. I find that most people that use the
> > database approach simply do not use attributes in their code at
> all.
> >
> > Those that do usually have fields that are designated by some
> > type of standard. For us that would be MARC. However, even if
> > that is a better scenerio, I cringe to think of typing in
> > dates twice or even three times in order to create a
> > normalized string.
> >
> > If these types of attributes are to be done as the data is
> > entered, this would put an incredible burden on the data
> collector.
> >
> > Further, without the EAD tag set, it seems to me that a
> > search engine would really have to do double duty to get to
> > the data (AACR2 date; ISO 8661 date).
> >
> > Finally, I would think that crawling through a proprietary
> > software would be much more difficult than an XML document.
> >
> > These are my reasons for sticking with XML rather than
> > databases. I see a separation between data collection
> > software and mark up/display of that data. Mapping the
> > datatypes seems to be the key, but context
> > (heirarchy) conveys information I would not want to try to
> > capture in a database format.
> >
> > Mike Ferrando
> > Library Technician
> > Music Division
> > Library of Congress
> > Washington, DC
> > 202-707-4454
> >
> > --- Richard Davis <[log in to unmask]> wrote:
> >
> > > Hi again
> > >
> > > Liz's post was very clear and interesting. I just wanted to
> > elaborate
> > > a couple of points:
> > >
> > >
> > > Elizabeth Shaw wrote:
> > > > It is not that archival data is particularly unique but it is
> > > true
> > > > that highly nested linear data stored across many fields in a
> > > > database is more difficult to retrieve and reconstruct.
> > >
> > > It hadn't occurred to me that anyone might think of storing
> > every last
> > > <emph> in its own field or row. As you suggest, it doesn't
> sound
> > > like
> > > something to be recommended, nor does it seem very relational.
> > >
> > >
> > > > But I would argue that perhaps the archival community should
> move
> > > > away from the notion of thinking of its data as a linear
> > > document.
> > > >
> > > > If you move away from that notion, then storing the descrete
> data
> > > > elements that describe a collection and its component parts
> in a
> > > > database begins to make more sense.
> > >
> > > This is the approach I've taken, and still favour, at least for
> the
> > > time
> > > being. The finding aids I've dealt with are ISAD(G) based, and
> all
> > > seemed strongly field-oriented. Within each component field,
> > > greater
> > > granularity is preserved by using the markup for the equivalent
> EAD
> > > element. At the moment, little further use is made of this
> markup,
> > > except for transformation to HTML. But valid and meaningful EAD
> can
> > > easily be reconsituted, offline or on-the-fly, for transmission
> > > over the
> > > web, for indexing, or for when the ultimate killer EAD app is
> ready
> > > to
> > > migrate to.
> > >
> > >
> > > > Although data may be indexed by elements for searching
> purposes,
> > > it
> > > > is usually retrieved as a chunk (with all the internal
> tagging
> > > > intact).
> > >
> > > This point is important, and often overlooked. Indexing is
> > > fundamental
> > > to any DBMS (including XML). None of it works at all, except in
> > > theory,
> > > without indexing.
> > >
> > > In modern RDBMS, indexing is exceedingly well implemented: for
> that
> > > speed and reliability alone, it's likely to be worth
> compromising
> > > the
> > > absolute integrity of a logical design. And, lurching back to
> the
> > > topic,
> > > MySQL's indexing features work extremely well, and include the
> > > option of
> > > "fulltext" indexing, which makes it very attractive for storing
> > > chunks
> > > of markup.
> > >
> > > MySQL has long lacked some core relational features. For
> example,
> > > I've
> > > had to implement referential integrity at application level,
> which
> > > (like Bartleby) I'd prefer not to. MySQL makes up for that by
> being
> > > fast, and free, and well-supported - though I understand
> PostgreSQL
> > > is
> > > also free, and fully relational, and performs well.
> > >
> > >
> > > > Depends on what you want to do. I will put my address book in
> a
> > > > relational database anyday but when I want to search
> Shakespeare
> > > give
> > > > me XML.
> > >
> > > At first I agreed with you, but then I had second thoughts: XML
> > > suits
> > > address books very well, probably more so than a heavyweight
> RDBMS
> > > -
> > > unless your address book is Yellow Pages! On the other hand, a
> > > complex
> > > network of multi-level descriptive records seems eminently
> suitable
> > > for
> > > the relational treatment.
> > >
> > > Seasonal regards!
> > >
> > > Richard
> > >
> > >
> > > --
> > > /
> > > \ Richard M Davis
> > > / Digital Archives Specialist
> > > \ University of London Computer Centre
> > > / Tel: +44 (0) 20 7692 1350
> > > \ mailto: [log in to unmask]
> > > /
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > All your favorites on one personal page - Try My Yahoo!
> > http://my.yahoo.com
> >
>
__________________________________
Do you Yahoo!?
Dress up your holiday email, Hollywood style. Learn more.
http://celebrity.mail.yahoo.com
|