User experiences with ICA-Atom for data entry, creating new finding aids, etc.
Creighton Barrett
Different kind of question this time! I'm curious to hear user experiences with regard to creating new finding aids in ICA-Atom. Are you doing data entry in the web-interface? Are you working with another platform and importing CSV or XML? A combination of both? What does your workflow look like? What challenges or problems have you encountered with new archival descriptions since you adopted ICA-Atom and how did you overcome them?
I've looked at some of the project documentation on the Artefactual wiki, which is great, but it would also be nice to have a space for the community to share this kind of user experience information or documentation.
Regards,
Creighton Barrett
Dalhousie University
Jessica Bushey
--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To post to this group, send email to ica-ato...@googlegroups.com.
To unsubscribe from this group, send email to ica-atom-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ica-atom-users?hl=en.
Adele T
I'll describe the situation at UNESCO Archives as an example. ICA AtoM
is more-or-less our first generation of archival management system.
We had some of our holdings entered into a CDS/ISIS database at some
point but that data did not get migrated anywhere. So, for legacy
finding aids I have a mix of file lists (excel, access, sharepoint)
and paper inventories. There is not much beyond the file title and
dates on these lists. I have been taking some of them and coding them
in EAD for import (because that's what I'm personally somewhat
familiar with). To do this I have a fairly complicated system of
filling in EAD tags around the columns of data in an excel sheet and
then dumping it into a shell of an ead-xml file. Because most of
these original files aren't ISAD-compliant, I usually have to go back
and edit each imported record anyway. Then I have also been doing
straight data entry for the paper file lists.
I should have mentioned right away that we host our system externally
so I am only seeing the client side of things. If you have access to
the SQL database you can probably do much more direct importing. (And
therefore much more damage if you don't know what you're doing!).
For authority records, I'm usually working in Word until it is final
and then cutting and pasting into the different fields in AtoM. My
administrative histories/biographies can be long so I prefer to
compose it that way.
Also, I am the only person working in AtoM unless we are lucky enough
to have some contract archivists. In general, I publish my
descriptions directly and have contract archivists leave their work in
draft status until I have a chance to review it.
Hope this helps.
Cheers,
Adele
Reference Archivist
UNESCO Archives
Maggie Shapley
We have been entering new authority records and archival descriptions
straight into the web-interface, though we've also created holding
forms for authority records and deposit descriptions (where you can
make notes against mandatory fields and the other fields we mainly
use) because of time-out problems, ie you're halfway through an
authority record and you get interrupted and forget to save and by the
time you get back to it you have to start again. There is a way to
extend the time-out period but this involves a code change and we're
on the wrong end of a long priority queue. We tend to compose the
authority record 'history' in particular on the holding form and cut-
and paste into ICA-AtoM.
Most of our finding aids were typed in the 1950s-1980s (and don't
follow the standard) so we are retyping information for authority
records and deposit descriptions from our previous amalgamated
authority record/deposit descriptions. An important point is that we
are effectively implementing ISAD(G) for the first time through ICA-
AtoM so all sorts of non-standard past descriptive practice (60 years'
worth) is being rectified at the same time and research often needs to
be done to complete the mandatory fields.
We are now using the CSV import facility to import Excel spreadsheet
lists of items (some originated as typed lists which we've OCRed and
Word documents using Tables, but we created more recent lists in
Excel) and this is good except where we've already entered the deposit
description. It seems that you can't attach a list of items to an
existing archival description (please correct me someone if I've got
this wrong!!) but have to create the parent level description as you
import the children. For this reason we have stopped entering deposit
descriptions where there is an Excel list so we can import items and
create the parent record at the same time. (The alternative would be
to create a second parent record and delete the first one once the
items are uploaded.) Related to the CSV import we are looking at a
more sophisticated checking process - eg checking for 256-character
truncation, merged cells, use of ditto marks etc. (things that might
throw out the import) - when I say 'looking at' we have spoken to
business analysts here but we are still in the queue.
I'm happy to share our experience with you if you have other specific
questions.
Maggie Shapley
University Archivist
ANU Archives Program (Noel Butlin Archives Centre, University Archives
and Pacific Research Archives)
Menzies Building #2
Fellows Road
The Australian National University
Canberra ACT 0200 Australia
+61 2 6125 9602
maggie....@anu.edu.au
www.archives.anu.edu.au
Victoria Peters
I initially imported our existing EAD collection level descriptions (created a few years ago for the Archives Hub), which was unproblematic. At the same time, I created authority records from scratch using the web interface. Like Adele and Maggie, I often use a half way house for authority records. I am happy to create a basic authority record directly in AtoM (ie type of entity + authorized form of name) but if the history is of any length or complexity, I create it in Word first and then cut and paste into AtoM. This is because the authority record becomes live straightaway on pressing Save and I don't want people to see my half finished ramblings! It would be much better if you could save a draft version of an authority record just as you can for an archival description.
I am now engaged in adding lower levels of description to the existing collection levels. All our existing lists are in paper form only. So far, I've just been manually entering the data (and taking the opportunity to correct, add information etc because, like Maggie's, our lists were mostly created before ISAD(G) and are less than ideal) but I'm going to experiment with OCRing the better paper lists. Ideally, I would then like to convert the OCRd list into a CSV file and import that but I'm doubtful as to whether our paper lists are in a suitable format for this (eg they're not set out in columns, so it's difficult to distinguish different elements of information). But OCRing would at least allow me to cut and paste instead of retyping.
I've experimented with different ways of adding lower levels manually to an existing published collection level description (cld) and have found it best to make a draft duplicate of the cld. I then add the lower levels (also in draft). When I've finished I delete the previous cld and replace it with the new one plus lower levels. It is possible to add draft lower levels to a published cld but when you've finished, you have to go back and change the status of each lower level individually, which takes ages! This way is much quicker.
As well as me, there are three others also adding lower level descriptions. Their entries stay in draft until I've had a chance to check them.
For brand new cataloguing (when we get the chance!), we catalogue directly into AtoM. I've found it smoothest to create a basic authority record first, followed by the archival description which I then link to the authority record. As before, any cataloguing done by my three colleagues is left in draft until I've checked it. At the checking stage, I also add any relevant subject index terms - I find it's more consistent for a single person to do the indexing.
Victoria
Victoria Peters
University Archivist
University of Strathclyde
Andersonian Library
101 St James' Road, Glasgow G4 0NS
Tel: 0141 548 5825
Fax: 0141 552 3304
Email: victori...@strath.ac.uk
University of Strathclyde Archives and Special Collections homepage strath.ac.uk/archives Follow us on Twitter twitter.com/StrathArchives
The University of Strathclyde is a charitable body registered in Scotland, no SCO 15263
On Apr 14, 3:19 am, Creighton Barrett <csbarr...@gmail.com> wrote:
> Hello again,
>
> Different kind of question this time! I'm curious to hear user experiences
> with regard to creating new finding aids in ICA-Atom. Are you doing data
> entry in the web-interface? Are you working with another platform and
> importing CSV or XML? A combination of both? What does your workflow
> look like? What challenges or problems have you encountered with new
> archival descriptions since you adopted ICA-Atom and how did you overcome
> them?
>
> I've looked at some of the project documentation on the Artefactual wiki,
> which is great, but it would also be nice to have a space for the community
> to share this kind of user experience information or documentation.
>
> Regards,
>
> Creighton Barrett
> Dalhousie University
--
Creighton Barrett
We're obviously just getting started and will probably be producing quite a bit of documentation on our implementation, procedures for migrating, creating descriptions, adding accruals, etc. The user manual really is great, but being informed about the experiences of those who have been at this a while would be even better. Finding the time to share this kind of information is often not possible, but when we can, we've been posting about our experiences with the Archivists' Toolkit on a blog (https://blogs.dal.ca/duasc/).
We can, and probably will, continue to do so with ICA-Atom, but I was thinking about a place to share and find answers to questions about how the community is handling routine archival functions with Atom. Something similar, perhaps, to the IFLA Success Stories database (http://fmp-web.unil.ch/IFLA/ - but it seems to be down right now...) or the LibSuccess wiki (http://www.libsuccess.org). I know structuring a wiki in a useful way can be quite time consuming, and there's no point in duplicating the user manual, but it would be wonderful to have a place to at least share any useful documentation (i.e. upload PDFs) we create.
Cheers,
Creighton
Victoria Peters
>Do you end up with the same URL when you delete and replace?
Hmm, that’s a very good point. No, you get ‘-2’ added to the end of the url. Not ideal when the aim is a persistent identifier! I may have to revisit this!
Victoria
--
Peter Van Garderen
Great discussion and great idea. Creighton, I've started a section on
the ICA-AtoM wiki for this, that's what its there for.
http://ica-atom.org/doc/Success_Stories
Please feel free to do with this page as you wish, add new pages, or
just post PDFs and links.
Anyone (other than spammers or bots) can request a wiki account:
http://ica-atom.org/doc/Special:RequestAccount
I've also provide a link to it from the ICA-AtoM wiki homepage
http://ica-atom.org/docs
Lastly, please note that the 1.3 release of ICA-AtoM will include a
number of improvements to the CSV import templates, including the
ability to specify a target parent description's permalink to avoid
having to delete & replace parent descriptions when using CSV import.
Cheers,
--peter
--
Peter Van Garderen
President/Systems Archivist
Artefactual Systems Inc.
http://artefactual.com
+1.604.527.2056
Adele T
You encourage me to look at CSV! Could you kindly share a string for
one record, file or item maybe? In particular, what does it look like
when you have two place access points or any place with multiple
values for one field?
Thanks very much,
Adele
UNESCO Archives
On Apr 16, 12:50 pm, Victoria Peters <victoria.pet...@strath.ac.uk>
wrote:
>
> I initially imported our existing EAD collection level descriptions (created a few years ago for the Archives Hub), which was unproblematic. At the same time, I created authority records from scratch using the web interface. Like Adele and Maggie, I often use a half way house for authority records. I am happy to create a basic authority record directly in AtoM (ie type of entity + authorized form of name) but if the history is of any length or complexity, I create it in Word first and then cut and paste into AtoM. This is because the authority record becomes live straightaway on pressing Save and I don't want people to see my half finished ramblings! It would be much better if you could save a draft version of an authority record just as you can for an archival description.
>
> I am now engaged in adding lower levels of description to the existing collection levels. All our existing lists are in paper form only. So far, I've just been manually entering the data (and taking the opportunity to correct, add information etc because, like Maggie's, our lists were mostly created before ISAD(G) and are less than ideal) but I'm going to experiment with OCRing the better paper lists. Ideally, I would then like to convert the OCRd list into a CSV file and import that but I'm doubtful as to whether our paper lists are in a suitable format for this (eg they're not set out in columns, so it's difficult to distinguish different elements of information). But OCRing would at least allow me to cut and paste instead of retyping.
>
> I've experimented with different ways of adding lower levels manually to an existing published collection level description (cld) and have found it best to make a draft duplicate of the cld. I then add the lower levels (also in draft). When I've finished I delete the previous cld and replace it with the new one plus lower levels. It is possible to add draft lower levels to a published cld but when you've finished, you have to go back and change the status of each lower level individually, which takes ages! This way is much quicker.
>
> As well as me, there are three others also adding lower level descriptions. Their entries stay in draft until I've had a chance to check them.
>
> For brand new cataloguing (when we get the chance!), we catalogue directly into AtoM. I've found it smoothest to create a basic authority record first, followed by the archival description which I then link to the authority record. As before, any cataloguing done by my three colleagues is left in draft until I've checked it. At the checking stage, I also add any relevant subject index terms - I find it's more consistent for a single person to do the indexing.
>
> Victoria
>
> Victoria Peters
> University Archivist
> University of Strathclyde
> Andersonian Library
> 101 St James' Road, Glasgow G4 0NS
> Tel: 0141 548 5825
> Fax: 0141 552 3304
Victoria Peters
I will when I get to that point - I haven't started experimenting with CSV quite yet! If anyone else has an example they could share now, that would be great!
Victoria
Creighton Barrett
Hi all,
Great discussion and great idea. Creighton, I've started a section on the ICA-AtoM wiki for this, that's what its there for.
http://ica-atom.org/doc/Success_Stories
This is great, thanks Peter. As I said, we're just getting started, but we'll be happy to share our experiences on the wiki once we have some successes to talk about! Heather Gordon's blog post about the City of Vancouver Archives launch is a great explanation of ICA-Atom for end-users, but it also says a lot about the process and how some issues (e.g., new terms and numbering) were handled internally. It gave us much to be excited about, so thanks again for taking the time to share that.
Best regards,
Creighton
Maggie Shapley
This is great news!
...please note that the 1.3 release of ICA-AtoM will include a
ability to specify a target parent description's permalink to avoid
having to delete & replace parent descriptions when using CSV import.
On Apr 18, 5:52 am, Peter Van Garderen <pe...@artefactual.com> wrote:
> Hi all,
>
> Great discussion and great idea. Creighton, I've started a section on
> Please feel free to do with this page as you wish, add new pages, or
> just post PDFs and links.
>
> Anyone (other than spammers or bots) can request a wiki account:http://ica-atom.org/doc/Special:RequestAccount
>
> Lastly, please note that the 1.3 release of ICA-AtoM will include a
> number of improvements to the CSV import templates, including the
> ability to specify a target parent description's permalink to avoid
> having to delete & replace parent descriptions when using CSV import.
>
> Cheers,
>
> --peter
>
> --
> Peter Van Garderen
> President/Systems Archivist
>
> On 12-04-17 08:50 AM, Creighton Barrett wrote:
>
>
>
> > Thank you Jessica for your interest and encouragement, and Adele,
> > Maggie, and Victoria for sharing some of your experiences so quickly!
> > When you're working with a word processor, copying and pasting,
> > processes for draft revisions, etc., is precisely the kind of user
> > experience in which I was interested. It is also interesting to here
> > about the prevalence of manual data entry, checking, etc. Victoria,
> > your point about adding lower-levels is especially well taken! Do you
> > end up with the same URL when you delete and replace?
>
> > We're obviously just getting started and will probably be producing
> > quite a bit of documentation on our implementation, procedures for
> > migrating, creating descriptions, adding accruals, etc. The user manual
> > really is great, but being informed about the experiences of those who
> > have been at this a while would be even better. Finding the time to
> > share this kind of information is often not possible, but when we can,
> > we've been posting about our experiences with the Archivists' Toolkit on
> > a blog (https://blogs.dal.ca/duasc/).
>
> > We can, and probably will, continue to do so with ICA-Atom, but I was
> > thinking about a place to share and find answers to questions about how
> > the community is handling routine archival functions with Atom.
> > Something similar, perhaps, to the IFLA Success Stories database
> > wiki in a useful way can be quite time consuming, and there's no point
> > in duplicating the user manual, but it would be wonderful to have a
> > place to at least share any useful documentation (i.e. upload PDFs) we
> > create.
>
> > Cheers,
>
> > Creighton
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "ICA-AtoM Users" group.
> > To post to this group, send email to ica-ato...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > ica-atom-user...@googlegroups.com.
> > For more options, visit this group at
>
> - Show quoted text -
M M Wisner
I just happened on this thread while I was looking for information about importing XML (authority records) and the way the software handles (legal and allowable) multiple values for one field. For instance, for an imported EAC-CPF record with more than one <occupation> or <place>, the display concatenates all values in one long string in one field. I wonder if the same is true for CSV import.
Melanie Wisner
Accessioning Archivist
Houghton Library
Harvard University
Cambridge, MA 02138 US
Adele T
probably missing out on something more fundamental. I am still trying
to work through EAD and I have given up (for the time being) on
multiple value (dates) and index fields (access points). It is not
the end of the world for me because the data requires proofreading
anyway so I enter this information after import, at the moment of
proofreading.
Peter, I am also happy to hear that CSV developments are already in
the works for 1.3. It seems like there are a lot of archives with
large amounts of data in spreadsheets! Funding this development would
be of benefit to a lot of people...if only we had the money to help!
Cheers,
Adele