ArchivesSpace.org - Latest Comments

Re: Specifications

Chris Prom — Wed, 05 Oct 2011 13:18:11 -0000

Thanks for your comment. The application will include some fairly simple reporting features. We are not sure exactly what technology will be used to handle reporting, but relevant specifications (e.g. accession, digital object, etc) list the precise reports that are to be included in the scope of work done under the grant. Also, we hope to put in place a structure to ensure that a reports module or plug-in can be developed by the community, within the overall framework of the application's sustainability model.

As part of the work that we are doing now to scope out the general data model and to ensure consistency among the specs, we would appreciate any specific ideas that people have as to specific candidate technologies that might be considered for the development of future modules or plug in capability. To a certain extent, that ability to implement a specific candidate technology will depend on the exact mix of technologies used to develop the application, as well as licensing issues. But, an essential first step would be to compile a list of both potential plug-ins and technologies that could accomplish this work. It seems to me that this would be an area where the broader community could contribute to the planning process in a tangible and immediate way.

Re: Main Modules

Chris Prom — Tue, 04 Oct 2011 20:25:13 -0000

Thanks Jordan. I believe that the function your require will be handled via an external document reference / subrecord.

Re: Main Modules

Jordon — Tue, 04 Oct 2011 18:07:06 -0000

Accession Records:

From an interface design standpoint, it would be helpful to display a link to the Deed of Gift in the same place that rights information is described.

Re: Supporting Modules

Kate Bowers — Tue, 04 Oct 2011 14:16:15 -0000

Additionally, in a consortial setting, having contact information specifically on a name is problematic. Contact is a relationship between a repository and name. For example, two repositories may have different specific contacts at the same auction house.

Re: Specifications

Deena — Mon, 03 Oct 2011 15:35:30 -0000

It may be too late for this, but I have found great use for the boolean user-defined fields in the AT accessions module, and wonder if AS could provide for more than just two.
Also, very picky, but the ATUG note indicated you were looking for comments on consistency, so I will just mention that I've noticed the values for boolean fields throughout the specs referred to as both Yes/No and True/False, and wonder if uniform values should be used throughout AS.

Re: Specifications

Epyers — Thu, 29 Sep 2011 00:44:10 -0000

Hey Chris,

I think we'd most like to be able to import bulk import MARC data into the Resource module, but it would be so helpful to be able to bulk export resource records (in MARC and EAD) and digital objects (we're currently using MODS)

Thanks!

Re: Supporting Modules

Jordon — Tue, 27 Sep 2011 12:43:34 -0000

On the topic of Name records, will AS have a place to record notes under the contact information? I did not see this referenced above, but I may have overlooked it. We've found the notes field to be a useful feature in AT, since it allows us to record notes about conversations with potential donors, essentially creating a virtual lead file. I'd love to see something more structured than notes (date of contact, ability to upload digitized supporting documents etc.), but at the very least adopting AT's free text notes field would be great.

Re: Specifications

Jordon — Tue, 27 Sep 2011 12:15:15 -0000

I have a couple of comments about the Location module. I don't really understand why the physical location of analog materials is being managed in a different place than the "virtual" location of digital materials (it take it this is what you mean by "web accessible" at the bottom of page one--I'm thinking more generally about offline digital material, like email accounts sitting on internal networked drives). To me, it's all location. What are the implications of hybrid collections--will users have to record location information in two different places? What if you are doing minimal processing and only want to record some basic location information? From a workflow perspective this strikes me as inefficient. Furthermore, with AT, you couldn't access the Digital Object management module from the Accessions module, which means you had to create a Resource record to record information about the location of electronic objects, even if you weren't ready to process the collection.

That said, there is a workaround for this that I hope AS will support. The "Location note" field is an easy way to record unstructured, rudimentary location information about a collection: "Boxes 10-15 are located on A-level, and electronic records are location at G:\whatever." I would suggest that the Location note field be available in the accessions module of AS (it wasn't in AT). Also, it would be nice to have the ability to link out to a location the same way in AT's accessions module you could directly link out to "external documents." This way users don't have to highlight the URI in a Location note field, copy it, open Windows Explorer/Finder, and paste in the link to access the digital content.

But overall, I wonder why physical and digital location information should be managed in separate modules. To my mind, the location module would support the ability to link to servers as well as shelves.

(That you're doing an excellent job is implied and should preface all of these comments.)

Re: Specifications

Jordon — Tue, 27 Sep 2011 11:45:32 -0000

Chris, truth be told I don't think I know what a data model is! But if I can describe my suggestion, it might be nice if there were an optional field in the repository module to record a sub-repository, and therefore have multiple sub-repositories related to a parent repository. I explored this from the EAD side a couple years ago when we ran into this challenge using AT, and I don't event think EAD's element set allows for, I guess you can also call them, nested repositories.

If we kept things as-is, as I see it, if different units (Archives, Manuscripts) within the same department (Special Collections) chose to set up separate repositories, they would operate a completely distinct repositories with no relationship to each other. And if you are looking at inter-institutional consortia using the tool, the repository then becomes the University, not the Special Collections department, right? I guess this is just something to ask ourselves if the complexity of the data model required to achieve this outweighs any benefits. Ultimately I defer to your all's decision on this.

Re: Specifications

Chris Prom — Tue, 27 Sep 2011 09:57:53 -0000

Jordan, Thanks for the comment. We are looking at the data model for the repository architecture right now, so this request is timely. Do you have any ideas as to a data model that might be able to accomodate it?

Re: Welcome!

Chris Prom — Tue, 27 Sep 2011 09:56:21 -0000

Shelley, thanks for your comment. We'll consider this as a potential option for the 'rapid data entry' portion of the tool.

Re: Specifications

Ed — Mon, 26 Sep 2011 14:39:26 -0000

What is the plan for report generation in ArchivesSpace? The current mechanism for creating and modifying reports is way too complicated. We've found ourselves creating reports outside of AT and querying MySQL directly.

Re: Welcome!

Shelley Erwin — Fri, 23 Sep 2011 17:39:47 -0000

Since processing of big collections is now frequently done using spreadsheet software for container lists in progress (Excel, Access), it is a problem for processors if the software cannot provide a full spreadsheet overview of the container list at any given time. Please considered adding a feature to ArchivesSpace that enables a full container list view, with option for editing (find/replace, insert, delete, copy, paste, etc.).

Re: Specifications

Jordon — Fri, 23 Sep 2011 17:03:07 -0000

Regarding repository records, how about sub-repositories--that is, multiple repositories under an administrative unit?

Ex. Anytown University Special Collections: University Archives
Anytown University Special Collections: Manuscripts Department
Crosstown University Special Collections: University Archives

etc.

I can see this coming up where you have multiple institutions using one instance of ArchivesSpace, like a consortium.

I don't see a reference to sub-repositories--how would you recommend handling this?

Re: Specifications

Ed — Fri, 23 Sep 2011 13:32:06 -0000

Hi Chris,

There's actually a bug in AT that prevents searching by repository. So, if you are user with access to multiple repositories, there's no easy way to just see one. AT made the repository id as a field you could select for searching (but not displaying in the Accession List) but apparently in the code it was hardwired to always query with your default repository regardless of what you specified.
We use 2 repositories to do records management with AT; we move destroyed and returned accessions to a separate repository.
So, searching and sort by repository would be helpful. Hope this makes sense.

Re: Specifications

Chris Prom — Fri, 23 Sep 2011 12:10:25 -0000

Thanks. I've made a note that we should review the classification language in the accession spec to update it and make sure it is treated the same as the identifiers will be in the Resource Spec. As far as the collection management subrecord spec, I'll consult with other members of the team. I am not sure exactly where the nature of the coll. mgmt subrecord is defined, but it needs to be defined somewhere--most likely in the Resources specification.

Re: Specifications

Chris Prom — Fri, 23 Sep 2011 11:43:56 -0000

Sharon, Thanks for the comment.

Scalability is a big deal and something that is given high priority in the design principles. It should apply to every record type.

Also, I would mention that there will be multiple ways to use the location feature. You need to look carefully at how the spec treats the issue of 'related' records and 'subrecords.' There is a difference between these two concepts in that a 'related' record can be attached to one or more of any given object type, but a subrecord is truly the child of one parent. In the case of locations, you'll need to make some choices. For example, you may want to define a short list of 'locations' that are rooms or ranges, and track the specific locating information for the shelf in the 'sub-record' part of the entry. That is currently how Archon operates, and that principle will be supported on the new application.

On the other hand, you may want to treat each shelf as a related record, that can be attached to one or more resource or child resource records. That method will also be supported. So, this is really an implementation issue.

Re: Specifications

Chris Prom — Fri, 23 Sep 2011 10:56:11 -0000

Hi Epyers, Which specific record types are you referring to. Resources? Resource components, Digital objects? Also, what file formats would you like it to take? CVS, EAD, or something else?

Archon has some bulk import/export capacity for certain records built in, and certainly the intention with the new app is to have bulk import or export. To me, it seems like this is a critical feature, but we need to treat it carefully since designing good importers is very tricky.

However, we'll look at this when doing our review, to make sure the specs are clear as to whether it is single record import. Whatever the case, I think writing importers might be a nice area to get community involvement!

Re: Specifications

Deena Schwimmer — Fri, 23 Sep 2011 10:37:08 -0000

Hi, Chris,
I'm referring to, for example, pp 2-3 of the Accessions spec., which refer to, respectively, a collection management subrecord spec. and a classification linked record spec.

Re: Specifications

Epyers — Fri, 23 Sep 2011 02:51:47 -0000

Wondering about bulk import/export functionality. Is this going to be upgraded from the current functionality that allows only single records to be imported/exported?

Re: Specifications

Chris Prom — Thu, 22 Sep 2011 17:36:56 -0000

Deena,

The classification function in Archon will be handled through identifiers in the Resource Spec. That area is not included in the draft that is on the site, but will be added as we go through the revision process.
Regarding collection management, I am not sure what you mean. What is currently a 'collection' in Archon terms will be know as a resource as the new tool, and you will be able to browse, search them, etc.

Re: Specifications

Deena Schwimmer — Thu, 22 Sep 2011 17:24:42 -0000

Did I miss an explanation of where specs for functionality like Collection Mgmt or Classification are? It's a little hard to evaluate whether Accessions/Resources specs seem complete without being able to see what will be handled in these functions.

Re: Specifications

Sharon Nelson — Thu, 22 Sep 2011 15:07:23 -0000

Is there anticipated to be any limit to the number of Location records (or elements that make up the location records) that ArchivesSpace can handle? For instance, we have 20 floors in our building, each with an average of 5,000 enumerated shelf spaces on each one - so about 100,000 shelves.

Similar question for the other Modules - especially Resource Records, Name Records, Accessions, Digital Assets. Any functionality or data storage problems anticipated for large institutions with voluminous data and many discreet entries?

Re: Specifications

Chris Prom — Thu, 22 Sep 2011 14:43:08 -0000

Thanks for the comment Ed. In your last paragraph, are you asking for a way to sort/list resources by repository?
Chris

Re: Specifications

Ed — Thu, 22 Sep 2011 14:37:02 -0000

In the Resource module, there needs to be a status for tracking whether a resource needs to be cataloged (MARC export) or has been cataloged (exported in MARC). It's in the Accession module and needs to be in Resources too. This is a big issue for those of us cataloging our resources to university library catalogs. In the same line of thought, why not have User Defined fields in the Resource module like there are for accessions?

For users with multiple repositories in the same AT instance, there needs to be a way to sort them by repository. This is a current bug in AT.