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

From: Anne Lawrence <[email protected]>
Sent: Wednesday, 27 April 2022 12:34 am
To: Fitchett, Deborah <[email protected]>
Cc: DSpace Technical Support <[email protected]>
Subject: Re: [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.

Yes, all of us who deal with metadata here breathed a huge sigh of relief when 
the script was implemented. CSVs with 20 columns are a lot to handle. But they 
sure beat the same ones with 50+ columns!

Anne


On Mon, Apr 25, 2022 at 6:06 PM Fitchett, Deborah 
<[email protected]<mailto:[email protected]>> wrote:
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: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On Behalf 
Of [email protected]<mailto:[email protected]>
Sent: Friday, 22 April 2022 4:39 am
To: DSpace Technical Support 
<[email protected]<mailto:[email protected]>>
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.

We also have "en" as our default language code.  "*" and [] are added as you 
describe. And we get deposits from Elements as you describe. Our solution has 
been a nightly script to convert everything to [en], as reported in 
https://github.com/VTUL/vtechworks/issues/737<https://github.com/VTUL/vtechworks/issues/737>.
On Wednesday, April 20, 2022 at 10:41:57 PM UTC-4 
[email protected]<mailto:[email protected]> wrote:
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<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:

  1.  Records already in DSpace when we use the Edit Metadata functionality – 
this mostly does what we tell it transparently, but experimentation shows that 
on saving, any null language codes get saved as '' instead. I suspect this is 
hard-coded and we’ll just need to live with it.
  2.  Records manually submitted direct to the DSpace workflow – these seem to 
automatically add our instance’s default language en to some fields; * to the 
Creative Commons license fields; and null to other fields. Is there somewhere 
we can edit any/all of these defaults?
  3.  Records submitted from Symplectic Elements via SWORD v2 – these come 
across as null, except a dc.provenance field is created by DSpace with en. 
We’re checking with the vendor whether we can specify language codes on their 
side, but I thought I’d better ask on the DSpace end are there any configurable 
defaults in SWORD?

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
+64 3 423 0358<tel:+64%203-423%200358>
[email protected]<mailto:[email protected]>
ltl.lincoln.ac.nz<http://ltl.lincoln.ac.nz>

––––––––––––––––––––––––––––––––––
Lincoln University
Te Whare Wānaka o Aoraki
––––––––––––––––––––––––––––––––––


________________________________

"The contents of this e-mail (including any attachments) may be confidential 
and/or subject to copyright. Any unauthorised use, distribution, or copying of 
the contents is expressly prohibited. If you have received this e-mail in 
error, please advise the sender by return e-mail or telephone and then delete 
this e-mail together with all attachments from your system."
--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx<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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/c252f0c8-b036-4e08-9fca-a8f0416e22e3n%40googlegroups.com<https://groups.google.com/d/msgid/dspace-tech/c252f0c8-b036-4e08-9fca-a8f0416e22e3n%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Anne Lawrence
Repository Application Administrator
Virginia Tech | University Libraries (0434)
Newman Library, Room 420
560 Drillfield Drive
Blacksburg, VA  24061
(540) 231-9320 | [email protected]<mailto:[email protected]>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/ME3PR01MB7524DE06B1BF94D03AD20437C5FD9%40ME3PR01MB7524.ausprd01.prod.outlook.com.

Reply via email to