2021-03-02 Meeting notes

@Randy Kuehn

@Maggie Hughes

@saron tran

1. https://archivesspace.atlassian.net/browse/ANW-886

2. https://archivesspace.atlassian.net/browse/ANW-1157

3. https://archivesspace.atlassian.net/browse/ANW-961

1. Recommend

   1. Thumbnail: will change to a more standard thumbnail with

   2. Control of digital object display dimensions:
      Pass - think this would be useful
      Will not do at this time, potentially outside the scope of ArchivesSpace, may revisit after larger community decisions are made regarding digital objects

   3. Responsive digital object display: Pass
      See b above

2.  Fully support. (Reminds me of recent ANW-942.) Icon at each level of the heirarchy that contains a digital object (collection, series, file) – inherited from lowest level. Recommend tagging Usability sub-team before passing.

3. I like this one. In the PUI archival objects show the hierarchy up to the different series and then to the collection (resource) and then to the repository-- and I think digital objects should function the same.

input from colleagues: I’m with Miloche on 1 and 2—I wonder with #3 if there’d be a way to distinguish digital objects that are digitized from analog collections vs. born digital objects that really are part of hybrid analog and digital or solely digital collections, and if institutions and researchers would find that distinction useful or not.  I definitely understand where the user is coming from who made the request, though I appreciate that once you click on an individual digital object you get the full contextual information.

Marcella

Here are my comments:

1. I agree with your idea of having an outside team work on the translations.  This is something that would be nice to have but I'm sure there are other bugs and or enhancements that are a higher priority.

1. I don't think this is a bug, instead it should be changed to an enhancement request.  I can't find it in the manual but I know as an ASpace trainer, we tell people that diacritics are WYSIWYG.  In other words, they should be entering it directly rather than as hex keys.  I agree it would be great if both worked but I believe ASpace is working as expected.

1. I think the Found in: label should only include the repository.  Instead, for a digital object you can have a new label of something like Linked to:  [name of resource/identifier/series that digital object is linked to].  The digital object isn't actually "in" the analog collection, instead the digital object is its own collection, and is just related to the resource record it's linked to.  This will make it easier to identify digital objects that are linked to resource records vs. those that stand on their own.

--Miloche

My take on #1 isn't so much who​ is doing i18n, but rather that if some team wanted to, it's really difficult when strings are baked in the XSLTs.  If someone copies the whole XSLT template over to a copy and translates all the strings to French, it'd also be really a pain to keep it in sync going forward.  There also isn't a provision for easily finding and extracting all the translatables.

Pulling all the translatables to one file of variables (https://stackoverflow.com/questions/12086231/how-to-do-i18n-with-xsl-and-xml) would at least get people thinking about translateable strings, and at least to some degree would mean a change to the XSL layouts could happen once, not in every language's copy.

It's not pretty work to pull all those out as vars in XSLT, and even then it's still not in something nice like a .po ('gettext') file.

But, if someone really wants a different language, they can translate the XSLT files we have now.  So, I don't think it's a very high priority.

(God help us if someone wanted to print out the PDF in an right-to-left language like Arabic or Urdu).

Tom

1. Close, recommend plugin

2. Awaiting more information, Maggie will split off ticket for second item that Usability will look at

3. Pass with having linked records added after the existing breadcrumbs

@Daniel Michelson

1.  Request for specific reordering of the elements in the collection overview view of the PUI. Part of this was already rejected at our January 5 meeting ( ). Recommend closing as repository specific.

2.  Ticket wants a conservation note (defined in DACS) added as a type of note. Note types are determined by EAD, not DACS, so this ticket should be closed.

3.  This ticket wants the publish status of agent records set by whether they are linked to a published record, rather than a checkbox in the agent record. Strongly recommend closing this ticket, there are good reasons (particularly with the launch of 3.0) that it may be desirable for an unlinked agent to be viewable in the PUI.

4. I’m biased, since I submitted this, but I think having the merge top container function act differently than the other functions in the “manage top containers” screen should be avoided unless there is a good reason.

1.  Close, too repository specific. Thank for the mock-up.

2.  Close

3.  Close, link to Smith script

4.  Pass

@saron tran

1. I think this is okay. I am curious to know how ArchivesSpace has dealt with translations in the past. I wonder if something like this could be done with a team providing support to people who are willing to translate to other languages (like a hack-a-thon / transcribe-a-thon). Or just some documentation that can help people who are willing to contribute the translation part which may or may not exist already.

2. Bug report. I really like how they reported this one (with the description and the screenshots to go along with it). I think this should be fixed.

1.  Pass for community developer

2.  Closed will not do, ArchivesSpace does not support non-UTF-8

@Maggie Hughes

1.  Pass.

2. Asking to add ability to create a top container from the Manage Top Containers page and add a view of the collection tree to select an archival object to link to. Not sure how often this comes up.

1.  Pass, using “temporary type” as term

2.  Close, will not do

@Angela White

1.  This should be pretty easy to do, but do we want to do it? Mine are organized in priority order in our instance, but I only have a handful.

2. We passed this one last meeting, so yes! It seems like a good idea.

3. This seems like a good way to make data cleanup easier--in addition to imports, most of the errors my students make is related to mis-categorizing subjects and agents.

@Matthew Neely

1. This ticket is requesting the additional functionality of being able to set the orienation of Top Containers. Currently this only applies to Container profile using Extent Dimension. This seems logical as it’s possible that an individual Top Container can have an different orientation when stored on shelving would ensure space calculator is accurate.

2. This ticket is requesting a related resources option to be added to Resources. They are requesting the same functionality as is used to add Related Resources in an Accession record. This seems to be a good idea but probably needs to be done as a replacement for the Related Materials note to ensure correct EAD mapping. Also would want to ensure against broken links as a repository manager. Would need to consider how this might work in the PUI.

3. This ticket is requesting that the EAD 2002 importer has the functionality added to created digital object identifiers using the id attribute in the <dao> EAD tag. I can see the logic in this request but the Digital Object Identifier is not exported as EAD 2002 from ArchivesSpace, so the data would be lost on export. METS MODs seems to be the only way to export the Digital Object Identifier. ArchivesSpace does not apply IDs to DAO on export as it does with other EAD 2002 tags.

1. Close, suggest two container profiles

2. Awaiting more information based on impact of similar implementation in the new agents module

3. Pass

@Althea Topek

1. I think this happens because the DO unique identifier doesn’t export in the xml so duplicate DOs can be created when importing.

2. Is there enough information in this ticket to move forward?

3. I didn’t have this experience while running other reports but there is a considerable amount of white space. Can this be cut down?

@Randy Kuehn

1. Recommend local plugin or push trivial if group decides it’s useful

2. Recommend: pass
   Add ability to create MARC record from accession record to retain accession record details (provenance) and avoid duplicate work