2021-02-02 Meeting notes

@Angela White

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

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

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

1.  This ticket asks for machine-readable dates for access restrictions using the spreadsheet importer. This seems like a helpful addition. I’m not sure about the amount of work involved, but I don’t see any obvious downsides to this addition.

2.  This ticket is asking for a column for medium in the extent area of the spreadsheet importer. It’s unclear what they’re asking for to me--there’s a column for extent type that isn’t limited to spatial measurements, and it maps exactly to the staff interface extent section. I suspect this is unnecessary, but I think I’d need some clarification to be sure.

3.  This ticket asks for a publish (true/false) value for digital objects and file versions in the spreadsheet importer. This seems like a reasonable request and a good idea, since the notes fields all have publish options.

1.  Pass

2.  Close - other fields available

3.  Pass - add 3 columns

@Matthew Neely

1.  This ticket is seeking to add deaccession sub records to Digital Objects. This would mirror Resource records which already have this. It seems a logical request but I do wonder if this is already handled by accessions and resource record workflows where deaccessions can already be recorded?

2. This ticket is seeking classifications to be added to Digital Objects. The ticket was created to identify a means of mapping legacy digital object metadata into ArchivesSpace with their preference being to use classifications rather than convert to subjects. I think we could request further information on why subjects could not be used.

3. This ticket is seeking a solution to display in linked resources within Agents all resources associated with that agent together with resources linked to any parent or child agents related to the agent being viewed. Comments in the ticket show that this could be cumbersome for some repositories. Options to search for keywords in SUI also might make this unnecessary to take forward for implementation?

1.  Close - lack of demand

2.  Pass - Trivial

3.  Close - will not do

@Althea Topek

1. List: all “notes” (except “preferred citation”), linked agents, linked subjects, and published external documents

2. Published, related accessions should display in the PUI as “related unprocessed material” (similar to published related resources as “related collections”)

3. Needs more information? No comments since 2015; is this still an issue?

1.  @Althea Topek will compile a list of notes - will revisit at the next meeting.
   Pass

2.  Pass

3.  Close

@Randy Kuehn

1.  Recommend adding record types to publish preferences (Global, Repository, & User)

2.  Recommend

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

   2. Control of digital object display dimensions: Pass - think this would be useful

   3. Responsive digital object display: Pass

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

1.  Close - benefit?

2.  Discuss next meeting

3.  

@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.

@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.

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.  

2.  

3.  Discuss next meeting

@Maggie Hughes

1.  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.

2.  Pass.

3.  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.  Discuss next meeting

2.  

3.