Meeting ID: 954 7939 2806 Passcode: 965674 One tap mobile +13126266799,,95479392806#,,,,,,0#,,965674# US (Chicago) +19292056099,,95479392806#,,,,,,0#,,965674# US (New York)
Dial by your location +1 312 626 6799 US (Chicago) +1 929 205 6099 US (New York) +1 301 715 8592 US (Germantown) +1 346 248 7799 US (Houston) +1 669 900 6833 US (San Jose) +1 253 215 8782 US (Tacoma) 877 853 5257 US Toll-free 888 475 4499 US Toll-free Meeting ID: 954 7939 2806 Passcode: 965674 Find your local number: https://lyrasis.zoom.us/u/ahUXQvjfH
Participants
@Maggie Hughes
@Randy Kuehn
@Daniel Michelson
@Matthew Neely
@Althea Topek
@saron tran
@Angela White
@Mark Cooper (Unlicensed)
@Lora Woodford
@Christine Di Bella
Goals
Discuss digital object tickets (First 10-20mins. of meeting)
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
Responsive digital object display: Pass See b above
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.
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:
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.
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.
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
Close, recommend plugin
Awaiting more information, Maggie will split off ticket for second item that Usability will look at
Pass with having linked records added after the existing breadcrumbs
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.
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.
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.
Close, too repository specific. Thank for the mock-up.
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.
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.
Pass for community developer
Closed will not do, ArchivesSpace does not support non-UTF-8
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.
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.
We passed this one last meeting, so yes! It seems like a good idea.
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.
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.
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.
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.
Close, suggest two container profiles
Awaiting more information based on impact of similar implementation in the new agents module