Comments for ArchivesSpace http://www.archivesspace.org building a next-generation archives management tool Fri, 02 Dec 2011 22:01:00 +0000 hourly 1 http://wordpress.org/?v=3.3 Comment on Specifications by » Updated drafts of specifications and new documentation now available » ArchivesSpace http://www.archivesspace.org/documents/specifications/#comment-30 » Updated drafts of specifications and new documentation now available » ArchivesSpace Fri, 02 Dec 2011 22:01:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-30 [...] Specifications [...] [...] Specifications [...]

]]> Comment on Specifications by Chris Prom http://www.archivesspace.org/documents/specifications/#comment-29 Chris Prom Wed, 05 Oct 2011 17:18:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-29 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. 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.

]]> Comment on Main Modules by Chris Prom http://www.archivesspace.org/documents/specifications/main-modules/#comment-28 Chris Prom Wed, 05 Oct 2011 00:25:00 +0000 http://www.archivesspace.org/?page_id=345#comment-28 Thanks Jordan. I believe that the function your require will be handled via an external document reference / subrecord. Thanks, Chris ____ Chris Prom chris.prom@gmail.com Thanks Jordan. I believe that the function your require will be handled via an external document reference / subrecord.
Thanks,

Chris
____

Chris Prom
chris.prom@gmail.com

]]> Comment on Main Modules by Jordon http://www.archivesspace.org/documents/specifications/main-modules/#comment-27 Jordon Tue, 04 Oct 2011 22:07:00 +0000 http://www.archivesspace.org/?page_id=345#comment-27 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. 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.

]]> Comment on Supporting Modules by Kate Bowers http://www.archivesspace.org/documents/specifications/supporting-modules/#comment-26 Kate Bowers Tue, 04 Oct 2011 18:16:00 +0000 http://www.archivesspace.org/?page_id=347#comment-26 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. 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.

]]> Comment on Specifications by Deena http://www.archivesspace.org/documents/specifications/#comment-25 Deena Mon, 03 Oct 2011 19:35:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-25 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. 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.

]]> Comment on Specifications by Epyers http://www.archivesspace.org/documents/specifications/#comment-24 Epyers Thu, 29 Sep 2011 04:44:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-24 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! 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!

]]> Comment on Supporting Modules by Jordon http://www.archivesspace.org/documents/specifications/supporting-modules/#comment-23 Jordon Tue, 27 Sep 2011 16:43:00 +0000 http://www.archivesspace.org/?page_id=347#comment-23 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. 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.

]]> Comment on Specifications by Jordon http://www.archivesspace.org/documents/specifications/#comment-22 Jordon Tue, 27 Sep 2011 16:15:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-22 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.) 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.)

]]> Comment on Specifications by Jordon http://www.archivesspace.org/documents/specifications/#comment-21 Jordon Tue, 27 Sep 2011 15:45:00 +0000 http://www.archivesspace.org/newsite/?page_id=39#comment-21 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. 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.

]]>