Monday, September 27, 2021, 1-2pm EST
- Chair: Kristina Spurgin
- Notetaker: Paige Morfitt
- Zoom Link: https://zoom.us/j/82790225209
- CLAW MIG MODS simplified mapping
- Example MODS for CLAW mapping
- Draft Recommendations
- Feedback on Mapping from ICG, Part 2
- Wants/Needs/Questions Open Document
- Working Ideas
- Kristina Spurgin
- Paige Morfitt
- Charlie Tillay
- Rosie Le Faive
- Melissa Anez
- Karen Gorss Benk
- Heather Campbell
- Chris Day
- Abigail Gulya
- Alex Kent
- Seth shaw
- Kirsta Stapelfeldt
- Mandy Ryan
- Wesley Teal
- Rachel White
- Ksgerrity
- Announcements
- No meeting October 11 (holiday)
- Use Cases with Kirsta
- Taxonomy Manager demo with Rosie
- Discussion about importance of Drupal fields (if there is time)
- Announcements
- No meeting October 11 (holiday)
- Taxonomy Manager Demo with Rosie
- When managing metadata in islandora, a lot of it will end up in taxonomy vocabularies. (Ex: geographic location which is rich in taxonomy terms. You can put all types of describing things into taxonomy terms. You can add in descriptions, alternative names, latitude and longitude, etc. Once you have that in there.).
- It’s possible (through views) to export and tweak that data, though, build in methods now are not very good and Media use vocabulary - as of now - you can edit it one by one.
- When you structure a taxonomy now, it appears like a view unlike media where you can select a (or multiple?) media term and do an action . How taxonomies are set up, you cannot do that.
- However, there is potential for a module called Taxonomy Manager. It adds a secondary vocabulary interface. This interface allows you to select multiple terms at once, and bulk edit. And you can edit without going to a new page. However it still requires you to work one by one, and it’s unclear what would happen if you have over 1,000 terms.
- You can bulk export (it’s a text box like OpenRefine) where you copy and paste the list of terms. That text box also allows you to bulk edit terms all at once. However, this just works with names (and other terms) and not other features such as uri, descriptions, etc (this goes for both exporting and importing).
- We could do further investigation on other taxonomy modules like one that has term merge features (which doesn’t work with the most up to date versions).
- This is better than what there currently is. Having the ability to batch ingest terms all at once is good because if you add a new item you have to go back and forth from the item form to the vocab term form. It’s not perfect, but it’s much better than what is there now. Taxonomy Manager would be good regarding use with student workers.You can give people the ability to create, edit, update and delete, and not give students the delete function. You could set it up so students could update and edit, and not unpublish also. You can have vocabulary-set permissions as well. The understanding is that, you can version taxonomies, and roll back changes incase someone mass changes terms (removes pluralizations). Bulk deleting vocabulaires -it is hard to do, even if you wanted to do it. With basic vocab built in, you need to do it at once. With taxonomy manager, you have to check all and delete (there is no select all box)
- Issues known on this include :
- Scale -- if you have thousands of things in your vocab, it may not be a good tool,
- Export and import only deal with term name -- and no way to export descriptions or external uris, ect. For import, you can only import names.
- No merge functionality,
- No migrating term to different vocabulary,
- No bulk “do action” (like what happens with media terms)
- A good example of similar work to this in Islandora 7 : https://www.drupal.org/project/wt_getty, however this would only maintain library terms relevant to the library collection and this doesn’t address multi field issue -- (so the multiple fields you’d have that describe your term like latitude and longitude).
- Alexander created a linked agent field for I8: https://www.drupal.org/project/linked_data_field. You can configure this to Getty and LCSH, but it doesn’t bring anything into Islandora (does not bring taxonomy terms into your system and is not linked). This stores terms as text fields.
- Desired behavior would be any field we create (entity related field) we’d like the flexibility to use auto-look up in either type of field. That would be a use case
- Use Cases with Kirsta
- Presentation
- No consensus on what makes a good use case.
- MIG’s use case: (https://docs.google.com/document/d/1oyba3HJngwgAiQz8yasmOBZ5iM2coDdpnsGERiSs1DA/edit)
- Listing what we don’t want to see, maybe say “as a metadata librarian, I need to see what vocabulary this term is coming from”
- So listing what exactly you are accomplishing can help developers -- there is more there than what the use case says to make it clear.
- If drupal allows you to autocomplete from different vocabularies, why can’t it tell you which vocab?
- What is the process of defining functionality as it should be? Looking at names specifically , when made MODS mapping (https://docs.google.com/spreadsheets/d/18u2qFJ014IIxlVpM3JXfDEFccwBZcoFsjbBGpvL0jJI/edit#gid=0) followed MODS that allowed different roles. We did ask for this, and what we got was a flattened version.
- We need islandora defaults to be flexible as MODS is (and reflect the fact that no two institutions have the same MODs fields).
- Issue we’ve had creating use cases: we need to work within the current framework, in some cases unmaking decisions that have been made to make our work easier.
- Broad use cases need to have a why. It is possible to unmake decisions that are made, specifically if it doesn’t meet your needs. You shouldn’t need to work around the system.
- Good to get together and discuss needs. - There needs to be more discussion with developers and interpretation. Ideal to have back and forth with developers, opposed to short simple answers.
- One main issue: metadata should be fields on nodes.
- In the github issues repository you can see the shared set of use cases as how we want islandora to behave now.
- We want to get the community to document use cases as issues in the github issues list. So that use case can be there in the community. And it needs to be testable. So instead of saying “more terms” say “we want to manage 6 or 7,000 terms. And in the case of use cases, you can see the work done.
- October 25, 2021