Public question about default EAD integration for the next release

[dp...@metro.org]

Good Morning everyone,

As some of you may know the EADC ESLN project (Empire Archival Discovery Cooperative) led by Jennifer Palmentiero and Developed/supported by Zack Spalding has been using and helping build into Archipelago Finding AID capabilities that can live side by side, connected to your other item/digital collection level Digital Objects.

All the work that has been done in conjunction between the awesome Jen and Zack team and our archipelago one is of course Open and shareable and we are very grateful that EADC has always seen openness and sharing as a core attribute of all their work. We (all) have been discussing if providing a default implementation (means the Webform needed to describe a full Finding AID, quite long and complete) and the Twig templates to provide Descriptions with nested containers (extra complex) plus the Twig Templates for EAD2002 XML  and EAD3 XML are something you people would see as desired and needed but also as an opportunity to collaborate from your repositories with the EADC project without any further data processing. Some may see this as a complement of existing systems like ArchiveSpace, but we (core team) really see this as a valid complete alternative, congruent with our platform's values and ready to solve many Archival problems without caging you into Formats.

This implies a lot of site building to make sure its seamless and discovery works as you would expect from us and of course training.

And this of course also opens the discussion if having an Archipelago that covers all the bases is a good option v/s having  niche specific implementations, which in turn opens the discussion of needing/wanting more community collaboration on doing so.  Every implementation basically means getting together and building with what exists solutions (no coding, but some Twig and Documentation writing is desired) and we love doing that and could do it for ourselves but as you may suspect we have only limited amount of hours every day and many tasks at hand.

Please don't be shy, a few words in reply to the whole group (don't get me wrong i really love your direct emails, don't ever stop sending those! but this discussion could benefit from public visibility) would help us get a better sense of user needs/hopes. Even a "i don't care" means a lot for us.

Finally, kudos to Jen and Zack for all their work implementing this and also for the admirable EADC community engagement and open process. There are a lot of caring archivists involved in the project and the whole process has been guided by a sensible collaborative effort which includes guided testing, public feedback, teaching and discussing and of course long after hours of genuine caring

Best!

Diego Pino

[Nate Hill]

I'm happy to chime in with my thoughts on "Archipelago that covers all the bases" vs "niche specific implementations."

I think we all would kind of want both available, correct? I'd love to have the swiss army knife with all the tools on it, but when I am actually going on a camping trip somewhere I typically don't want all the tools they just make my knife heavy and hard to carry. I want to bring my streamlined knife that only has the things I need.

For one audience, having the ability to add or edit the tools on the swiss army knife is pretty great. With enough skill, you could really end up with a pretty tricked out knife with a unique set of tools for your situation. And of course the beauty of the open source project... become a contributor! Build new tools everyone can add.

But for other audiences, prepackaged knives with all of the configs and templates ready to go would be pretty great. If my friend calls me and says "let's go camping tomorrow!" I still really want to go on that trip, but I also don't have time or resources to build a custom swiss army knife. 

Hopefully I'm not overdoing it with the metaphor here. Curious what others think?

N

--
You received this message because you are subscribed to the Google Groups "archipelago commons" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archipelago-com...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/d2592bbf-ad4f-4441-895d-0bf1d3214f15n%40googlegroups.com.

--

Nate Hill

natehill.net

[Susan D'Entremont]

In a perfect world - one in which we don't overload Diego and Allison - I would like both. For many CDLC members, the "prepackaged Swiss Army Knife" would be especially useful. These are the members who don't have the resources (expertise, labor, money) to do all the customization. The prepackaged tools will be something that will help them make their operations much more efficient. They will get a lot of bang for the buck with prepackaged tools because they currently have very few tools at all. 

However, our members that are already experimenting with Archipelago are not those members because that experimentation requires time and skill. I know these members appreciate your tools with a lot of customization possibilities, and the team has been responsive in working to make a lot of the desired customizations viable. Archipelago may not be as much of a game changer for these members as for the members I mentioned in the first paragraph because they are already using tools to do the job. It's just that Archipelago has the promise of doing those things better and more cheaply. I suspect this second group would use Archipelago more, though, but if you develop the perfect prepackaged knife, who knows!

Susan 

Susan D'Entremont (she)

Digital Project Manager & Continuing Education Coordinator

Capital District Library Council

28 Essex St, Albany NY 12206

518-438-2500 x130

su...@cdlc.org

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/CALceJ37SYu5g65Y9pFt9sSNZ44WRGAc8vcbKiW%3DMiy0%2BLg%3DDUQ%40mail.gmail.com.

[Nate Hill]

Fortunately, Susan, Diego & Allison have been given ample resources to expand their team as they see fit :) that said, their work ethic is sort of out of this world and incomparable. Humbling. Admirable.

Thanks for chiming in though, I totally agree. I think it might be an order of operations thing too. First, the knife that can do a zillion things. Next, some more refined products made from that. 

--

Nate Hill

natehill.net

[dp...@metro.org]

Hi Susan,

I agree on the use cases and the different type of users+the budget/staffing reality. Just to extend on the idea, even if we decide to ship niche specific implementations every archipelago will always be capable of everything else. Nothing of this implementations idea hinders the use-extension to other use cases, to use other niche specific settings over your initial setup or even come up with your own needs (a core value). 

Still site building implies experimentation and figuring out what features should be enabled, what to facet on, how to make certain things accessible and give others less importance and ready to use by default for certain "pre-packaged" needs is something we may(more like really) require community feedback. 

Independently of us hiring more staff (as Nate says we have the need and the budget and we are going to focusing on core shared values, GLAM affinity and of course humor too), use cases tend to be a lot more snowflake-ish institution by institution that one would expect and not even the best caring staff (and good with dad jokes) can replace your own ideas of what a repo is and should be.

To start, RC2 is pretty close to be a turn key Cultural Heritage default deployment. We cover almost every aspect/media and now with CreativeWorkseries support via IIIF and Mirador and also full Nested Collections and Objects navigation inside a single viewer we are closer and to be honest RC2 does more than any other repo we have used before. Metadata profiles may need more work and we come up with more setting for sure. That said we may want to have official Release Machines as feature rich as possible always. The type of profiles/niche settings I was thinking of are:

1.- Good for all Base deployment (and here the question of adding EAD to it) 

2.- Archives, Community and Education collections: Which implies Digital Objects, Collections and EAD and cross discovery and also export and harvest endpoints to interact/push data to EADC, Arclight but also probably new code to import from ArchiveSpace.

3.- Data repositories. With more visual and post processing and discovery support for tabulated data.

4.- Bio collections. Fully Darwin Core based with external Biodiversity vocabulary access for LoD

5.- Exhibit rich repo. One that has extra tooling to reusing/and generating dynamic exhibits.

6.- IR, strong on making scholars happy (Stats, profiles, etc) and strong of Access Control and Ark Ids/DOIs

7.- (can be part of 1. too) WebArchiving fine tuned machine. 

Wonder where we leave Multi language deployments. Since each language needs to be setup manually, should that be an install option for every choice?

So again 1 will have every capacity and with some care/knowledge (or superb documentation) may be made into 2-7. Also eventually 5 will be part of everything too.

Only concern is that the more niche-specific we go, the more every live in production repo will look exactly like the other! And knowing our people nobody wants that. Impossible to have a win-win situation on looks to be honest so certain customization at user level will have to happen.

Thanks again Susan, I really appreciate your reply here and also appreciate your kind words.

 Everyone else, do you have thoughts or would like to complement needed features to cover from 2-7? Diverging comments are welcome too. 

Hugs

Diego

[Nate Hill]

I am not a collections manager myself. But I imagine that cases like 2-7, especially when offered to under resourced institutions, are best served by streamlining admin interfaces and workflows.

Drupal's admin tools, and thus Archipelago's admin tools, allow you to do an unbelievable number of things using the GUI. While it is phenomenal that so much can be achieved by metadata specialists or collections managers without needing to be software engineers, the fact remains that there are so many choices and so much potential configuration that it takes a great deal of time and practice to understand how to do whatever you want to do with the system. Again, no prob and really quite desirable for many - but also limits the overall potential audience.

My instinct is that creating niche Archipelagos for these unique cases are really about enhancing the user experience on the admin / workflow end, and mostly about removing noise from the billions of Drupal configs available.

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/3e70dc0e-7207-470b-b28c-08c833fb6951n%40googlegroups.com.

--

Nate Hill

Executive Director

Metropolitan New York Library Council

metro.org

917-375-0332

[Jason Barone]

Just weighing in here briefly:

 

I think the power and flexibility of vanilla Archipelago might be acting as a barrier to adoption.  It can handle pretty much everything one can throw at it, but without specific turnkey builds we might be scaring off users that are less comfortable adminning a Drupal site than they are using a standard interface to input data.  If we can boil it down to a limited set of specific niche builds, we might be able to get easier buy-in and we increase the likelihood that the product hits with the users. If they get used to their niche build, they’re more likely to expand into other arenas with Archipelago.

 

To build on the Swiss Army Knife analogy, I use my SAK as a last resort when I don’t have any other tools.  It’ll do the job, yeah, but I’m much more comfortable using other tools that I’ve acquired over the years for specific purposes. A lot of librarians and library folk may already have these specific tools, and may not want to switch to a SAK because it’s a last resort backup, but they will switch to a better-made, better-feeling, or easier-to-use tool.

 

I feel niche implementations may serve the overall project better; if Archipelago can do almost anything (which it can!) we should show how it can do specific things better than the competition to really market it to institutions and users.

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/CA%2BDQROM9tb8YvtU9pYEtMG-UC7m9u%2B0M2eLFUCZyvpuobGsQRw%40mail.gmail.com.

[dp...@metro.org]

Hi Nate, I fully understand where you are coming from regarding the Drupal Admin and I agree that navigating the many interfaces may be challenging. Overriding and building a new Admin UI on top of an existing one may be a complex operation because it is a moving target (Drupal itself) and in that sense not a sustainable approach. 

Basically means having to make our UI change/catch up with every core or contributed module change. I do see a benefit of making certain operations exposed in a different way, in specific for Views (Collection listings, filtering Object types) and Facets. 

In my humble opinion the main downside is actually not the code involved but that by removing the Noise you will also make any Drupal contributed documentation obsolete for our users which means we will be using Drupal not but not Drupal (and then some may ask why drupal?) and the docs to maintain on our side may be too much. There is probably a lot we can do with the right permissions and good theming. Some things I would like to keep exposed as a knowledge -diffusion- experiment.

I'm positive there is for sure a balance in between and eventually we will come to a good middle point. I'm pretty sure. I also see the benefit of teaching and using wisely more energy on teaching core Drupal because our dream is also that users can mix and match other Drupal capabilities we do not provide. I would not subtract us from that process, you may never hear from our team something like "oh that is on Drupal, go and learn that somewhere else, or weird statements like "deal with that Drupal problem without our support" but I would also would like to avoid double documentation that may become obsolete with Drupal 10.

Thanks to both! This is a good discussion and all your opinions are already being noted and taken in account for further releases 

Best

Diego

[Nate Hill]

"There is probably a lot we can do with the right permissions and good theming."

This may be an excellent way to think of it. Perhaps the niche versions are more like really well honed roles. 

There can be a full Archipelago behind every instance, but constraining options and adjusting theming for different roles would work.

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/db415d4c-8af4-4466-a0bc-b73dfa91d0cfn%40googlegroups.com.

--

Nate Hill

natehill.net

[Susan D'Entremont]

Thanks - this makes sense to me. You are correct about each institution, especially GLAM institutions, being snowflake-ish. I think at some point you will have to say here is the product with lots of options. If you have niche options that aren't in the product and don't have demand from others, you can adapt what's here to meet your needs or pay us a bunch of money to make it an exact fit for the institution. But I don't know when that point will be, and it seems you enjoy the challenge of solving these issues, so will leave that up to the discretion of those wiser than myself. 

Is the 1-7 list in your priority order or just a list? :-) 

I admit that I had never heard of Darwin Core before, but isn't that a cute name for the standard?

Susan 

Susan D'Entremont (she)

Digital Project Manager & Continuing Education Coordinator

Capital District Library Council

28 Essex St, Albany NY 12206

518-438-2500 x130

su...@cdlc.org

On Thu, May 20, 2021 at 5:09 PM dp...@metro.org <dp...@metro.org> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/3e70dc0e-7207-470b-b28c-08c833fb6951n%40googlegroups.com.

[Giancarlo Birello]

Dear friends,

I'd like to add just another point of view about this interesting discussion.

Our first presentation at repositories workshop 10 years ago was a "talk" between IT department and Librarian where Librarian exposes needs to IT and IT answers with code to satisfy and make reality her requests. This was the way we used to manage our repositories deployments with addition of a third part: scientists and humanity researcher. The continue discussion and exchange between these components allowed us to build really useful repository front-end appreciated by a large kind of people.

When IT department doesn't talk with Librarian and Scientist, code is only a group of bits really far away from people needs. Better results are reached when each part respects the other one skills. Also this collaboration is effective only if the platform (Archipelago) provide as many tools as possible to IT department which mission is manage code to make reality Librarian and Scientist dreams.

So, as IT department, I'm really happy with Archipelago (thanks a lot Diego and Allison) because with its lot of tools make be able to satisfy Librarian and Scientist desiderata and I have to manage options and theming (because it's my skill) to reflect what Librarian and Scientist need as result of their skills.

Have a nice flavored Sunday, friends.

Giancarlo

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/CALceJ35_vxnoGUrP_UgFe9E%3DyPvw43bXHKTqDEe%2Budo4ysCHJQ%40mail.gmail.com.

[dp...@metro.org]

Dear Giancarlo,

Your vision and words are always encouraging. I totally I agree, communication between library users and implementers, end users and library users and everyone involved in this type of project is key and by having built tools that facilitates those needs to be expressed using each parties skill-sets and expertise we are reaching a certain balance that makes us very happy. Can it be better? Yes of course it can, we have lots to do yet and code/UI/UX and documentation will get better. As all the exposed tools start to permeate into each one's forte and through learning, testing, breaking and experiencing (and more learning/teaching and then refining) we make these tools part of each one's well known toolbox, lowering the initial barrier, we may start seeing a more comfortable use of what is provided and lots of more dreaming and fulfilling.

Thanks to you, you have been a stakeholder, partner, coder, tester and user but also a wise reference since the beginning and I speak for Allison and I, a trusted and appreciated core part of the team.

Hugs

[dp...@metro.org]

Hi Jay,

Sorry for the delay in answering. You are right. The level of flexibility the current Archipelago implementations (Vanilla) may be overwhelming many times. There is a lot happening here (code/UI/UX but also different workflows/ways of seeing Digital Objects and their metadata) that was not be attempted before (like letting users "own" their metadata) and we humbly assume there is a risk of exposing too much/too complex in its current form, as you detect correctly, probably not suited right now as a "click and play" platform. 

Why? I think we are still learning what "play" may mean for everyone involved and we risked mass adoption by diverging from the well-known not only to differentiate the system but also to serve needs that were really obscured (or subdued) by the fact that existing tooling/software did not even allowed other ways and imposed a workflow, one that became by practice "standard" but not necessarily the one a Metadata professional, archivist, cataloger would wanted to have if "asking for" could have had any real effect on their past software driven experiences. Not saying what we have done is perfect. I'm totally aware we are far from that.

Even if larger user base is desired (currently not that small neither), at the current stage, where knowledge transfer is key, i (can't speak for the full team here) feel its still priority to build capabilities through documentation, self exploration and training and have more experienced/power users in our community that can help shape use cases. So more that larger adoption for now I want more discussion and deeper engagement that empowers skills present in our domains that are not the ones we developers have. There is always my personal fear of enforcing canned solutions before we have enough community members knowing at least how much can be done/what to expect and imposing as Developer "ways" before listening long enough to our users, specially the ones dealing with Digital Repositories on their daily work.

As we move into a clear path (and communal awareness) of what "playing" means for each domain, sub domain and institution, without the constraints of what a previous system could do, the ease of use will become more relevant and we will put more work on hiding certain flexibility, empowering the features we know are key and through that we may reach at least for certain configurations of Archipelago a "click and play (and replay)" state.

Thanks a lot Jay

Best 

[Jennifer Palmentiero]

Happy Monday everyone,

A little late to this party, but wanted to chime in from the perspective of a non-technical person who has been working with Archipelago for about a year now.

Building the web form for finding aids (for Empire Archival Discovery Cooperative) is where I got started. The form builder is very approachable. And fun! And powerful! Overtime, I've learned other parts of the system with the support of Diego and Allison (and my right-hand man, Zack!). I'm really grateful to them for showing me how/where to do things myself rather than doing them for me. It's amazing how much power I have at my fingertips. I'm now at the point where I might try to find a setting on my own before asking for help. ;-)

The more I learn, the more I can help others. Removing features for certain users would be a pretty subjective task. I say we start with documentation and training to see if we can build a community that collectively knows how to do a lot of things with the available tools. I'll never share one line of code with this community - because I can't write one line of code - but I can tell people where to find a drop-down menu or a check box (among other things!).

And to bring this back to where Diego started: +++ to one system that can rule them all (with "all" being defined locally). We're happy to share our finding aids form with anyone who wants to use it or modify it to meet their needs. Our form includes just about all of the DACS elements. What we have done is not a replacement for ArchivesSpace, because we don't include any collection management functions. But I'm fairly certain those functions could be built into Archipelago!

Cheers,

Jen

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/8add3cd2-a85e-40cb-a1a5-fd5ac2ffdab3n%40googlegroups.com.

--
Jennifer Palmentiero
Digital Services Manager
Southeastern New York Library Resources Council
21 S. Elting Corners Rd.
Highland, NY 12528

Phone: (845) 883-9065 ext. 116 | Fax: (845) 883-9483
www.senylrc.org
www.hrvh.org
Like us on Facebook! www.facebook.com/SENYLRC

[Megan Tyne]

Hi Jen,

 

Thanks for such a positive email.

 

I also am a non-technical and non-librarian person and am new to Archipelago.  I do have some experience using Drupal.  I have been so impressed by Archipelago and the community and the support from Deigo and Allison.  

 

The organisation I work for is embarking on a major digital library build and overtime I hope to be able to contribute something back to the community. 

 

We definitely will require a Finding Aids form and the ability to search for and list similar collections.

 

I think the more features out of the box the better.  People with strong Drupal or developer backgrounds will not be limited by these features and can customise quite easily.  For people from a non-technical background having something that gives some early wins and seems easy to use with some core functionality is a great advantage.

 

Thanks to everyone who is working on Archipelago.  It is such an elegant and robust solution.

 

Thanks,

Megan

 

 

 

Megan Tyne

Chief Innovation Officer

Association Montessori Internationale

 

https://www.montessori-ami.org

 

We connect Montessori to the world.

 

From: 'Jennifer Palmentiero' via archipelago commons <archipela...@googlegroups.com>
Date: Tuesday, 25 May 2021 at 1:42 am
To: archipela...@googlegroups.com <archipela...@googlegroups.com>
Subject: Re: [archipelago-commons] Public question about default EAD integration for the next release

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/e9eedfb8-6963-1db2-c95a-6164a99a808f%40senylrc.org.

[Alli Lund]

Hello everyone,

Hope you all had lovely weekends!

Following along with Diego’s earlier comments, thank you all for your thoughtful responses about Archipelago’s default capabilities and potential configuration customizations. 

Giancarlo, many thanks to you especially for your kind and wise words, and for all of your wonderful contributions to Archipelago’s development and discussions (absolutely a much “trusted and appreciated core part of the team”!!). Also, many thanks for sharing links to your ongoing documentation on Archipelago's Traditional Installation Notes page. 

Jen, many thanks to you also for your kind and wise words, and for sharing about your experiences learning, using, and ultimately teaching others to work with Archipelago as part of the greater EADC project. The webform you created and implemented, and your attentive and deeply considerate work with EADC partners is simply amazing. Thanks again to you and Zack for bringing so much inspiring, positive, and extremely useful examples related to extending Archipelago for finding aids creation and sharing to this community. 

For those who are not aware of the ESLN (Empire State Library Network) Institutional Repository Pilot Project, sharing some brief context for earlier messages in this thread. Susan and Jason/Jay, along with Tim Spindler are the librarians leading the ESLN IR Pilot Project, which was intended to test the waters for interest and viability of an ESLN-administered consortial institutional repository service. For this pilot, METRO deployed (five) early-RC1 vanilla Archipelago instances, using lightly customized-for-IR webforms and metadata display templates, and a small set of demo content for each instance. METRO provided ~10 hours of basic Archipelago training to Susan, Jay, and Tim—who then went on to work with a group of 3-4 pilot library partners to kick the tires of the vanilla Archipelagos. This Pilot Project is wrapping up and Susan, Jay, and Tim will soon be presenting the results of their Pilot Project at an upcoming ESLN Resource Sharing Meeting in early June (complemented by Nate Hill, representing METRO/Archipelago). You can find more information about the ESLN IR Pilot Project on their Google Group (which requires an invitation/request to join: esln-i...@lilrc.org). This post contains Diego’s answers to the set of the questions collected during the Pilot Project’s testing. Thanks to all involved for sharing the experiences of this Pilot Project. We’ve learned a lot from the testing work of the Pilot libraries, and wish everyone well in their future IR endeavors.

To circle back to Diego's question of integrating basic EAD/finding aid related webforms, displays, and related functionality—and in good time also the full Release Machines list—is there any functionality in those items (2-7) that stands out as particularly needed or desirable? Any specific use cases or scenarios you feel are not addressed by the configuration profiles/settings summarized in this list?

Jen and Megan (and anyone interested), for the EAD/finding aid related basics, we have been thinking of including a webform and attendant metadata displays, other options that reference the DACS/EAD Required Elements, along with a few additional Non-required Elements that are commonly used. Of the various Non-required Elements, do you have any that you would recommend?

And one last note related to documentation for Archipelago: we recently made some adjustments, edits, and expansions to Archipelago’s documentation on GitHub: https://github.com/esmero/archipelago-documentation/tree/1.0.0-RC2. We have more guides and updates in the works, but please reach out on any of the various channels (including the Archipelago Slack channel just for documentation) if there ares\ specific guides/explanations you would like to see—or contribute to. :) 

Thanks again everyone. Have a great start to your week!

Allison

Allison Lund

Digital Projects and Metadata Librarian

Metropolitan New York Library Council

metro.org

To view this discussion on the web visit https://groups.google.com/d/msgid/archipelago-commons/DBBP194MB119487023885AFEA1F7909768F269%40DBBP194MB1194.EURP194.PROD.OUTLOOK.COM.