Re: diglib: More on databases

[Carol Hixson <chixson@OREGON.UOREGON.EDU>]

Relating to JQ's point number four, I think part of this can dovetail
nicely with efforts already underway with the Access to Collections group
and with the upcoming outreach effort that was discussed in Department
Heads yesterday. Understanding relational databases and how they work is
an important component. Equally important is deciding on the content and
structure of the data. The Access Group is pulling together a subgroup to
recommend core data elements for any library-sponsored database.
Coincidentally, I just finished a fairly lengthy email to a graduate
student who is going to undertake a "cataloging" project here on campus.
I'm meeting with her this afternoon to discuss her project in greater
detail. A large part of my focus with her is the structure and content of
the data that she will be putting into her database. As I spent the time
on that this morning, I justified it to myself thinking that it could form
the foundation of a module that could be used internally to develop our
own databases and as a part of the new outreach effort. This is where I
have expertise. Thank heavens JQ and Bob and some others have expertise in
software selection, use and the design of databases from that angle.
Together, I think we can put together something very useful.

Carol

On Fri, 2 Mar 2001, JQ Johnson wrote:

> Bob's analysis is, I think, right on.  A couple of additional points:
> 
> 1/ I think we need to (and can) come up with strategies that scale to 
> moderately ambitious projects.  In some environments one can expect the 
> potential implementors to evaluate appropriate technologies.  Most of our 
> staff don't have the time or the inclination to become knowledgeable even 
> to the level where they have a good understanding of what's possible.  Bob 
> is particularly valuable in this regard -- having an early adopter like him 
> gives us all an example.  But most faculty aren't early adopters; they need 
> more support.
> 
> 2/ technology evaluation problems are complex.  They often require trial 
> implementations (looking at specs can be misleading).  For example, Colleen 
> and I were really hoping that Ultradev would be a magic bullet that would 
> empower non-programmers, but the initial data from actually using it has 
> led us in different directions.  That doesn't mean that the different 
> directions won't pay off, though.  Per Bob's suggestion, I'll play with CF 
> Studio next.
> 
> 3/ we really do have a resource we aren't using effectively -- talented 
> undergrad programmers.  We also have courses that teach this stuff; any 
> staff member who took CIT381+CIT382 would come out of it with plenty of 
> expertise to be our library guru in this area (but correspondingly, would 
> have invested 100+ hours in training).  We also have a new staff member in 
> systems, which should provide a bit of relief.
> 
> 4/ As Bob noted, database design is a big issue independent from web 
> hosting.  It's one that as information professionals we should be more 
> knowledgeable in, and one that doesn't require us to become programmers. 
> I'd like to see us organize some internal training that focuses on teaching 
> interested faculty and staff more about this topic, building on the 
> existing strong understanding of information organization.  We could 
> structure it as we have in the past -- "how to use access" -- but I'd 
> prefer to see us put more into the basics of "what's a relational 
> database?".  As someone who has recently learned SQL I can certainly help 
> in that regard, but would like to identify other faculty who can as well. 
> I'm imagining 2-6 contact hours, not the 30+ contact hours that CIT381 
> involves.
> 
> 5/ having a few template projects is definitely the right idea, if coupled 
> with (a) having access to people on our faculty/staff with a bit more 
> technical info to help understand/explain, and (b) models for obtaining 
> more extensive technical help when the project justifies it (and has 
> funding for it).
>