When we (v5.8 XMLUI Mirage2) export a CSV from Batch Metadata Editing, we can get multiple columns for each metadata field due to different “text_lang” codes being assigned = eg dc.title, dc.title[], dc.title[en], dc.title[en_US], dc.title[*], etc. This is partially described at https://wiki.lyrasis.org/display/DSPACE/TechnicalFAQ#TechnicalFAQ-MetadatavaluesinCSVexportseemtohaveduplicatecolumns and I’m comfortable with using both the CSV and SQL fixes for existing data. But I’d like a more permanent solution for data created from this point forward which, as the page notes, depends on the import methods.
We have data from the following sources:
Our dspace.cfg file has
# Default language for metadata values
default.language = en
but this doesn’t explain why only some metadata fields are using that value while others are using null or *. I can’t find anything in any of the other config files or through the web interface. Is there anything configurable, or is the ‘fix’ to just periodically run either the CSV or SQL fix?
Deborah
––––––––––––––––––––––––––––––––––
Deborah Fitchett (she/her) MLIS, RLIANZA
Associate University Librarian, Digital Scholarship
––––––––––––––––––––––––––––––––––
Learning, Teaching and Library – Te Whare Pūrākau
PO Box 85064, Lincoln University
Lincoln 7647, Christchurch, New Zealand
––––––––––––––––––––––––––––––––––
Lincoln University
Te Whare Wānaka o Aoraki
––––––––––––––––––––––––––––––––––
Thanks, it sounds like there’s no control over the language codes from the Elements end, so a regular script seems like the easiest way to go.
Deborah
From: dspac...@googlegroups.com <dspac...@googlegroups.com>
On Behalf Of al...@vt.edu
Sent: Friday, 22 April 2022 4:39 am
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] Re: Where are metadata text_lang defaults determined?
Caution: This email originated from outside our organisation. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
--
All messages to this mailing list should adhere to the Code of Conduct:
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dspace-tech...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dspace-tech/c252f0c8-b036-4e08-9fca-a8f0416e22e3n%40googlegroups.com.
Repository Application Administrator
Virginia Tech | University Libraries (0434)
Newman Library, Room 420
560 Drillfield Drive
Blacksburg, VA 24061
One quirk to be aware of for any places that do this:
The metadatavalue table holds metadata for *everything*, including bitstreams, communities, epersons, etc, not just bibliographic metadata from items. It turns out (at least in our 5.8 instance!) that if you set a non-NULL text_lang value for a bitstream’s metadata value, then when you try to manually edit the bitstream name or description it appears to refuse to save.
More precisely, I think it creates a duplicate row in metadatavalue with the edited value, but the old value is the one that continues to display in the user interface. I didn’t delve into this too deeply but/because setting all of the text_lang codes back to NULL where resource_type_id='0' solved what had otherwise been a very mysterious problem!
So if/when we set up a script to make changes regularly, we’ll be limiting it to where resource_type_id='2' (ie items only).
(Resource types: https://wiki.lyrasis.org/display/DSDOC5x/Business+Logic+Layer#BusinessLogicLayer-Constants )
Deborah