Print

Print


Dear Yann,
 
With respect to the integration question you raise in point two, you are correct at one level but I believe that there is another way to look at this issue.   Library ILS software is vertically integrated but only within a particular vendor application.  The turnkey aspect of such systems seems the most convenient solution for the staff user who needs a complete toolkit to perform a range of functions.   But as someone who has moved MARC data between a number of utilities and local systems, this has been mixed blessing in three respects.  
 
1.   Sometimes the vendor does not provide all of the components of the system and we have to patch in another solution to get needed functionality.   Suddenly, the operation is no longer seamless.
 
2.   The tools the vendor provides are not "best of breed' and you find yourself stuck with a serials control or media booking or some other subsystem that has less than optimal functionality.  The selection process of ILS software is often a matter of compromise in selecting the feature set that most closely, but seldom in all ways, meets ones requirements.
 
3.   Vendors implement solutions that are not standards-based or that are not able to reflect standards upon data output.  This can leave you in a bind when you want to share data or migrate to a new application.   My colleagues have many stories to share on this subject during our recent implementation of a new ILS.
 
The lack of full vertical integration that you see in EAD is, in fact, the norm in web delivery of information.   HTML editors, database software, and web servers all must be synchronized, even if the details of that process are hidden from the various participants in the operation.   Most applications seem to require the bolting of some, if not all, of the components together.    This approach lets you employ the best and most standardized solution for each part.  One trades control for a certain level of complexity.
 
Michael
 
-----Original Message-----
From: Yann Nicolas [mailto:[log in to unmask]]
Sent: Monday, May 17, 2004 5:55 AM
To: [log in to unmask]
Subject: Tools for EAD

Bonjour,

Recently, messages concerning XML editors and EAD have been posted to this list.

As I read them, two questions stroke me :

1. It is clear that several tools are available to create EAD inventories, but all of them are generic XML editors, not specific EAD editors. At best, you can use specific EAD stylesheets to feed and adapt your generic XML editor. You can also use the .dtd or an .xsd (W3C XML schema) in the same way.
But is there any specific EAD XML tool ? If the answer is no, why ? Are generic tools sufficient ?

2. It seems that the various tasks concerning EAD instances (creation, indexing, display, search) are not made by integrated tools, but by different generic tools that are thereafter more or less integrated by each local EAD producer. It strongly contrasts with Integrated Library System.
It seems that this "scattered" configuration makes difficult such actions as :
- updating (if you change just a minor part of your finding aid, you have to treat it as a whole : changing a part in your editing tool, but charging the whole in your indexing tool)

Maybe my concerns come from some hidden (or patent ?) librarian's bias. Finding aids have definitively not the same needs as bibliographic records : not the same structure, size, rythm of creation and updating, not the same necessity of data exchanges between instituition....
Nevertheless, the "regular" life cycle of EAD intances seems unstable and non integrated. Isn't it an obstacle to a larger adoption of EAD ?

Merci de votre attention et � bient�t,

Yann


Yann NICOLAS
ABES - Agence Bibliographique de l'Enseignement Sup�rieur       
Service : Produits et Services
Dossiers : Portail Sudoc, Th�ses �lectroniques, CGM
04 67 54 84 25
mailto:[log in to unmask]