Well, we're off and running! So far, a few dozen have been recorded into the database. We are being very comprehensive in our inclusion of all pertinent data in the fields we have set up. This is possible because of a number of tweaks to the database that came about through much thought and discussion between ourselves and the CMA staff (thanks Rachel and Will). As said before, title, abbr. title, contributor name, role, type, publication and edition info. , call number, ISBN, OCLC, LCCN, LCSH, local headings, and Notes have all been included. With regard to this note field, it is this area that does, indeed, serve as the "catch-all", and we have developed a method of inclusion that is both clear and comprehensive. It is this area that could use some sort of improvement, from our perspective, so that this information would be entered by a different manner and yet linked to other fields relationally as well.
Yes, the thought that what we are finding out as we go along, what sorts of interconnectivities and interrelationships could be augmented and improved upon in the KE EMu system, could - concievably - be put into effect into future systems, and that this, in turn, might be helpful for other museum libraries around the globe, is an exciting prospect! We will soon have a chance to meet with our technical guru to discuss this...
Friday, March 21, 2008
More questions about Internal Codes...
Speaking with Rachel, regarding what would work best for the staff, and thinking about how the collection is shaping up phsyically, we've come to a couple of mutual conclusions. Firstly, both Rachel and ourselves see this collection as something that should be easy to access, use, and reshelve. We've determined that it's in the best interest for those using the collection to have all of the materials relating to, let's say furniture, together.
Using a traditional organization method, these elements are often relegated to different areas than the books that they support and/or complement. For instance, while books might be shelved first, there are journals, exhibition catalogs, and ephemera that relate to these various disciplines and genres as well. There is also the matter of class divisions - where a book about an artist would be located in a completely different location from the book on the artist's work.
As Lauren said, we have talked about a 3 or 4 letter internal code to be placed on books. This not only provides the staff with an efficiency of use greater than the traditional LC call number system, but also gathers these elements of the collection together. Books, journals, theses, ephemera, etc. are all contained in one area, and the potential to access and discover complementary research material becomes far greater.
We're in the process of refining these codes and thinking further about them. Should there be even more refinement with these, so that a number goes after the lettered code to further delineate objects? Such that, FUR1 = book FUR2 = journal FUR3= ephemera, etc..
Should this be a new field entirely, or is it adequate to enter this information into the already-existing field, "local heading 1"? This would seem to be a fine place to put them, but is it accurate enough, for descriptive purposes? Is there some sort of procedure for this type of internal coding already? Is this something that we can take liberties with, as far as the naming/selection of them goes? It would seem, since this is "our" system, that we could be responsible for their creation, as long as it is uniform...but perhaps this is just an assumption on my part.
Finally, there is the problem with, should they be in a seperate field, is it possible to print them out with the call numbers on the same item sticker, at the same time? If not, ...??!!!
Using a traditional organization method, these elements are often relegated to different areas than the books that they support and/or complement. For instance, while books might be shelved first, there are journals, exhibition catalogs, and ephemera that relate to these various disciplines and genres as well. There is also the matter of class divisions - where a book about an artist would be located in a completely different location from the book on the artist's work.
As Lauren said, we have talked about a 3 or 4 letter internal code to be placed on books. This not only provides the staff with an efficiency of use greater than the traditional LC call number system, but also gathers these elements of the collection together. Books, journals, theses, ephemera, etc. are all contained in one area, and the potential to access and discover complementary research material becomes far greater.
We're in the process of refining these codes and thinking further about them. Should there be even more refinement with these, so that a number goes after the lettered code to further delineate objects? Such that, FUR1 = book FUR2 = journal FUR3= ephemera, etc..
Should this be a new field entirely, or is it adequate to enter this information into the already-existing field, "local heading 1"? This would seem to be a fine place to put them, but is it accurate enough, for descriptive purposes? Is there some sort of procedure for this type of internal coding already? Is this something that we can take liberties with, as far as the naming/selection of them goes? It would seem, since this is "our" system, that we could be responsible for their creation, as long as it is uniform...but perhaps this is just an assumption on my part.
Finally, there is the problem with, should they be in a seperate field, is it possible to print them out with the call numbers on the same item sticker, at the same time? If not, ...??!!!
Thursday, March 20, 2008
The Catch-all Notes Field
We discussed at our last group meeting the possibilities of additional fields for publication data, contents, exhibition information, and other important data not able to fit into the current database. We agreed that though optimally, the KE EMu network would allow for greater detail, the cost of additional fields and the programming difficulties for mapping the data proved the Notes Field a better location for extra cataloging info.
The following entry from the database shows the Notes field in use:
On a related "note," Marc and I have been invited to meet next week to propose revisions to the Bibliography module of EMu and give input on our cataloging project and the limitations of the current database system. Exciting!
Processing
Marc and I are strategizing on the best ways to simplify our procedure. As of now we have no fewer than six steps to completing an accession of an unexamined book:
1. Search for the book in OCLC
2. Create a record in the DA database using the text itself and OCLC information (multiple steps)
3. Create a tag for the book with call number, title, and OCLC #
4. Pencil the call number inside the front cover of the text
5. Stamp the tag with a "completed" symbol in blue
6. Shelve the book
These steps are not overwhelming, but a few issues are in the way: 1) the pre-database volumes, 2) local call number creation strategy, 3) call number stickering, and 4) the limitations of the database which will not allow for more than one worker to enter books at one time.
1)Before the current database was completed, we did extensive amounts of work searching for books in OCLC and discovering patterns to help shape the new database. We have come to realize that all these pre-database volumes will need to be re-searched in OCLC, entered into the DA database, penciled, re-marked with a "complete" symbol, and shelved. 2, 3) We are still missing a step for creating a call-number sticker, which will be a great asset to the library users, and also a method for creating localized headings for these books. We have brainstormed about the sticker inclusion of the full LCCN + a three letter interior tag, like "FUR" for furniture, "CER" for ceramics, etc., but would greatly appreciate insight regarding established patterns for local holdings. Additionally, it may be of use to reserve the full LCCN for the database, and create a different method for the shelving stickers, perhaps something simplified for maintenance by non-librarians.
4) The database limitations have proven more difficult to overcome. We both feel that working together is incredibly helpful, but we must come up with a way to divide the work if only one of us can enter the volumes in a shift. We thought perhaps Marc could print OCLC records, and I enter the data, but this seems inefficient (both sets of eyes must look at each book). Is there another solution? We both feel that the cataloging experience is key, and each should work with the database, but we are stumped as to the best division of our time and talents.
1. Search for the book in OCLC
2. Create a record in the DA database using the text itself and OCLC information (multiple steps)
3. Create a tag for the book with call number, title, and OCLC #
4. Pencil the call number inside the front cover of the text
5. Stamp the tag with a "completed" symbol in blue
6. Shelve the book
These steps are not overwhelming, but a few issues are in the way: 1) the pre-database volumes, 2) local call number creation strategy, 3) call number stickering, and 4) the limitations of the database which will not allow for more than one worker to enter books at one time.
1)Before the current database was completed, we did extensive amounts of work searching for books in OCLC and discovering patterns to help shape the new database. We have come to realize that all these pre-database volumes will need to be re-searched in OCLC, entered into the DA database, penciled, re-marked with a "complete" symbol, and shelved. 2, 3) We are still missing a step for creating a call-number sticker, which will be a great asset to the library users, and also a method for creating localized headings for these books. We have brainstormed about the sticker inclusion of the full LCCN + a three letter interior tag, like "FUR" for furniture, "CER" for ceramics, etc., but would greatly appreciate insight regarding established patterns for local holdings. Additionally, it may be of use to reserve the full LCCN for the database, and create a different method for the shelving stickers, perhaps something simplified for maintenance by non-librarians.
4) The database limitations have proven more difficult to overcome. We both feel that working together is incredibly helpful, but we must come up with a way to divide the work if only one of us can enter the volumes in a shift. We thought perhaps Marc could print OCLC records, and I enter the data, but this seems inefficient (both sets of eyes must look at each book). Is there another solution? We both feel that the cataloging experience is key, and each should work with the database, but we are stumped as to the best division of our time and talents.
Friday, March 7, 2008
New paper tag info.
As we've started to enter the collection in the database, our needs for what is written on the paper tag we put inside each book has changed. Whereas before, when the database wasn't quite re-tooled and we were still figuring out what DB fields should be included in the form/table, prudence dictated that we include such information that we'd need to refer back to the item for entry into the DB. Now that the entries are being done on a per-item basis, the amount of information has lessened to a considerable degree.
At this point, we are merely using these tags to both represent the items in the collection that have been cataloged and organized on the shelf, and what their call numbers are. To this extent, we are still including the call number on that portion of the tag that sticks up out of the book (for obvious reasons of intershelving), but now marking those tags entered into the DB with additional notation (a nice BLUE dot). Additionally, the abbreviated title is also included, should the tag fall out and/or to refer back to the item when the call number stickers are matched up and put on. Personally, we are really excited by the thought of seeing the labels on the books; I think this is going to make the organization seem more tangible to our librarian sensibilities!
At this point, we are merely using these tags to both represent the items in the collection that have been cataloged and organized on the shelf, and what their call numbers are. To this extent, we are still including the call number on that portion of the tag that sticks up out of the book (for obvious reasons of intershelving), but now marking those tags entered into the DB with additional notation (a nice BLUE dot). Additionally, the abbreviated title is also included, should the tag fall out and/or to refer back to the item when the call number stickers are matched up and put on. Personally, we are really excited by the thought of seeing the labels on the books; I think this is going to make the organization seem more tangible to our librarian sensibilities!
Updated 'Record Type' field
After a productive meeting discussing the best possible way of handling those special items that are, quite naturally, expected to be found in a museum book collection (here, I am referring to the slim tome or pamphlet that is neither book, nor auction/exhibition catalog, nor journal), we collectively decided that the best way to address these small, random, but numerous items was to include them in the 'record type' menu as --- EPHEMERA. This now gives us 7 possible choices for selecting 'record type' in the database: article, book, book series, catalog, ephemera, journal, and thesis. Whether or not to give these items considerations equal to those for a book or catalog is yet to be determined....
Obviously, these vary in origin, relevance, and, most importantly, importance, as far as how often they will be accessed by the museum staff and to what extent they will be helpful. A liklihood is that they will probably receive a first level of description, with a single subject assignment and information entered into the notes field, but not much more. Their organization and addition to the catalog is a certainty. The priority of these items, however, is not as great of a concern as the main book collection, so they are being gathered to be tackled at a later time. Much like a seemingly rag-tag collection of gypsies, they are forming together and assembling themselves in one locale - proud of their heritage and unique aesthetic.
Obviously, these vary in origin, relevance, and, most importantly, importance, as far as how often they will be accessed by the museum staff and to what extent they will be helpful. A liklihood is that they will probably receive a first level of description, with a single subject assignment and information entered into the notes field, but not much more. Their organization and addition to the catalog is a certainty. The priority of these items, however, is not as great of a concern as the main book collection, so they are being gathered to be tackled at a later time. Much like a seemingly rag-tag collection of gypsies, they are forming together and assembling themselves in one locale - proud of their heritage and unique aesthetic.
Thursday, March 6, 2008
Complexities of the Access system...
Do we need an additional field to clarify the 'physical type' (i.e. pamphlet, book, etc.) , vs. 'physical description' (info. in the MARC 300 field)? With the number of small items containing various adverts, pamphlets, upcoming exhibit/sales info., etc. -- there must be a way for us to clearly define these...
This was our predicament, given the type of information we wanted to include and the format of the Access database. Did we want to create another field, and would this information be relational to the 'record type' field?
Was it possible to include this information in a string format - where: space ; space would not only work but be searchable? With issues regarding proper cataloging punctuation and whether the system would become confused and/or be able to recognize these individual components, we were temporarily confounded.
Ultimately, it was decided that we should create a new record type, to include all MARC 300 information in the 'physical description' field, and include any additional, pertinent info. in the 'Notes' field. This seems to be an adequate solution for access points and searchability issues.
This was our predicament, given the type of information we wanted to include and the format of the Access database. Did we want to create another field, and would this information be relational to the 'record type' field?
Was it possible to include this information in a string format - where: space ; space would not only work but be searchable? With issues regarding proper cataloging punctuation and whether the system would become confused and/or be able to recognize these individual components, we were temporarily confounded.
Ultimately, it was decided that we should create a new record type, to include all MARC 300 information in the 'physical description' field, and include any additional, pertinent info. in the 'Notes' field. This seems to be an adequate solution for access points and searchability issues.
Subscribe to:
Comments (Atom)
