[OPEN-ILS-GENERAL] SPAM: Some questons about Evergreen

[Jason Etheridge]

Hi Frances,

I'm one of the developers, so I can answer some of this.  I'll try to
skip whatever Jenn and Elaine already explained.

<snip>
> 4.  When I create a MARC record, is there somewhere that data about when
> that bib was created, or changed or who did it is kept?

There is.  Some of that information is displayed in a "Record Summary"
pane above the record in the staff client's version of the catalog.
I'll definitely add Creation Date to the display.

<snip bib_status and staff_only flags>
> Is there anything like that in Evergreen?

Right now, the visibility of a record is dependent on the state of its
items (which are easy to edit in batch).  I'm not sure of the design
rationale for not having a record level override of item attributes
like holdability and OPAC visibility, but if a strong enough case is
made for one it could be added.

<snip collections>
>So if in that branch they have a separate "Reference Collection"  Where
> do you put that information so the user knows to go to a special place,
> not the regular stacks to get the piece?

Elaine mentioned how PINES uses call number prefixes for this, but you
could also create "sub-libraries", and have them hang off of a
specific branch.  We could also make "shelving locations" more
prominent, if need be.

I think eventually we'll also have animated maps for pointing out
where an item is located. :)

> 6.  When I create a single item it nicely grabs the Dewey and LC call
> numbers from the MARC bib and lets me choose one and "Apply" it so I
> don't have to retype it.  It defaults to the Dewey number.  Can I assume
> I could default to the LC number if I wanted to?  Or not pick up the
> Dewey number?

This hard coded in the source currently, but could be made into
configurable option very easily.  PINES has also asked for a feature
to include call numbers in that list that are already in use for that
record, but not necessarily in the MARC.  That'll be coming too.

<snip>
> Is anyone having problems with putting copy and volume information into
> the call number field?  Are there any plans to have separate fields for
> that type of information?  It might be needed.

When we were designing for PINES, we found there was no real
consistency with how each library handled call numbers, so we just
migrated everything to one big text field like they were used to.  I
think Mike (our database guru and chief architect) originally wanted
to cut the call numbers up, and we can create extra fields easily
enough, but it might take some effort to come up with a unified and
configurable way of handling it for every conceivable library.
Discussion and examples are welcome!

<snip serials>
> Is there any plan to put a copy record between the bibs and
> items?  Or does such a copy record actually exist in the background
> somewhere?

Serials is outside my realm of expertise, but this feels like an
implementation detail, and maybe even a kludge (I'm probably fighting
against preconceived notions here), so I think it should require a lot
of discussion as we develop the serials module.  A "copy" layer may or
may not be the best way to implement this, and I wouldn't want to do
it that way just because every other system does it thus.  We might
come up with something better; we just need to enumerate all the use
cases.  I'd love to hear more about this.

> 8.  When I create an item, the bib did not show up in the pac until I
> checked in that item.  We don't do that.  We have too much stuff going
> through, it just goes to the shelf, they cannot stop and check it in
> before doing that.  Is there an option to not have to check it in?

There's at least one PINES library asking for that now, but I need to
figure out if the current behavior is due to actual PINES policy or
not.  But we can definitely make it a configurable setting.  As more
non-PINES libraries try out the software, we'll take any hard-coded
PINES-policy and turn them into options.  One of our goals is that
library software should never dictate library policy.  The software
should just enforce it where necessary (we're also against "babying"
the users, but sometimes that is asked for too).

> Actually we have some items where we have a flag "staff only" so it
> won't display in the pac and we have some bibs with that sort of "staff
> only" flag too.  Is there anything besides the status of the item that
> controls that in Evergreen currently?

There is an "OPAC Visible?" attribute on both items and shelving
locations that control this.

> 9.  When creating items there is an option to print spine labels.  I
> looked at that briefly.  It seemed like it did not work well with LC
> call numbers.  Is there somewhere that you set up a bit of code to break
> up LC call numbers?

This is hard-coded now, but if you can explain how to cut up and
appropriately wrap an LC call number as a mechanical process, then we
can do it.

<snip>
> 10.  Is it true that there are only Keyword indexes.  Do people think
> there is a need for the type of Browse indexes in current library
> catalogs?  Usually that is where the cross references and see also
> references in authority records have been used.

There are multiple search classes (title, author, keyword, subject),
but as far as browsing goes, we only have the shelf (Call Number)
browser currently, and the authority-based sidebars that basically
extract information from the search results and allow you to search
outwards.

There's been a bit of bias against browse lists in general (and A-Z
lists in particular) among the developers, but the shelf browser won
us over, and there has been a desire to make a more navigable
authority-based subject browser.

I'd like to see the browse list topic discussed more thoroughly, but
my personal bias is to question to the utility of alphabetical sorting
when dealing with vasts amount of data (though maybe our FRBR-ish
meta-record concept can mitigate that), especially in a world with
"Did you mean?" style suggestions and other means of discovery.  If we
could make it as easy and intuitive as flipping through a physical
dictionary or phone book, maybe.  Comments are welcome; we'll behave!

> 11.  One other thing.  Of course we would assume we would need to
> contribute to development if we were thinking of trying to use this, but
> do you think this software could work for a database of 5.2 million bibs
> and 7 million items?

Absolutely.  The minimum design goal was to be able to handle all of
Georgia and maybe parts of Alabama. :)  Mike could speak more on this.

> I'm sure we'll have other questions but as I start to look at this, I
> just want to make sure I am not missing some documentation or
> misunderstanding any of the basic functions.  Thanks.

Hey, thank you!

-- 
Jason Etheridge
GPLS -- PINES Development
http://open-ils.org/