Switching from "dc" to "dcterms" in DSpace

[Peter]

Hello,

We are considering switching from "dc" to "dcterms" namespace in our repository.

Is it technically possible without breaking any DSpace core functionality?

Although we do not use the newest DSpace version yet, but we are getting ready to update to one, so I would be interested to find out how would the newest versions handle this.

Tested replacing dc namespace with their equivalents in dcterms, and at least in DSpace 6 this results in disappearance of some data from landing page, but more important would be whether this is only a visual effect or the result of a more serious fault?

Thank you.

Peter

[Jorge Gustavo Spertino]

Hello everyone,

In my opinion it would be a problem to make that change.

I think that several functionalities linked to specific dc fields would be affected.

Your idea is very interesting, but doing it en masse would involve reconditioning several elements in configurations in my opinion. In addition to reconditioning the worksheet, which would be the least important thing in this case.

I only recommend it if you have significant knowledge or assistance, and in a trial instance.

Greetings,

Jorge

--
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 Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/e9ce1719-5125-4c81-b0e2-b6f4efb3b68fn%40googlegroups.com.

[DSpace Community]

Hi Peter,

I can verify that what Jorge says is true.  DSpace's User Interface (not only in 6.x, but also in 7.x) assumes you are using "dc" fields.  While it's not *impossible* to make the switch to "dcterms", I suspect it'd take a lot of effort to make it happen.  DSpace has always relied on the existence of many key "dc" fields for title, author, descriptions, etc.  To remove all those hardcoded assumptions would be a lot of work. If you still want to do it, your first step may be to search the codebase and configuration of any hardcoded references to "dc.*" fields, and replace them with "dcterms.*" equivalents.

Tim

[Reed, Marianne A.]

Peter, could you please share why your institution wants to switch to “dcterms” instead of “dc” ?  I’m curious about the use case for this. 

 

If you prefer, feel free to email me directly rather than replying to the list.

 

Best,

Marianne

 

Marianne Reed (she/her/hers)

Digital Publishing & Repository Manager

Watson Library, Room 470-G

University of Kansas Libraries

mr...@ku.edu

785-864-8913

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/c8929405-72fa-411d-8d62-165f94b56689n%40googlegroups.com.

[Peter]

Hello,

Thank you all for your interest in the topic and for your insights so far. It looks like transition to dcterms is less straightforward than expected.

The reason behind this issue is that I would prefer to stick with official DCMI namespaces only. DSpace introduces many unofficial elements, and although I presume they are well established already, this is difficult to determine whether they will be correctly recognized by increasingly abundant external tools. I wouldn't mind using dc namespace, but dcterms has broader scope, so this is why I thought I would focus on this set of terms at first. However, attempting to adjust our current metadata to fit a stricter dc scope could be worthwhile.

Best,

Peter

[Baer,Helen]

Hi Peter,

I hear you about the unauthorized DC qualifiers that are in the DC namespace. We had been using some of them in our repository, and for the most part I ended their use a couple of years ago. I tried deleting a few of these elements and it caused problems for our developers because as Jorge and Tim explained, some of those elements are hard-coded into DSpace.

Best,

Helen

---

From: dspace-c...@googlegroups.com <dspace-c...@googlegroups.com> on behalf of Peter <ad...@ispan.edu.pl>
Sent: Tuesday, April 9, 2024 4:56 AM

To: DSpace Community <dspace-c...@googlegroups.com>
Subject: Re: [dspace-community] Switching from "dc" to "dcterms" in DSpace

 

** Caution: EXTERNAL Sender **

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/5a587f0f-b73c-4d40-99cd-78addd65a9a2n%40googlegroups.com.

[Peter]

Do you think it makes sense to use dc terms (but still, only standard qualifiers) for basic metadata just to avoid braking DSpace and then dcterms namespace (again, official set) for extending metadata? Can it negatively impact the "harvesting" tools? I'm curious if anyone has any experience from this perspective.

Peter

[Fitchett, Deborah]

For us, the external harvesters we care about all use OAI-PMH. So for that purpose, we can use any schema/combination of schemas we like in DSpace itself (we’ve got a mix of dc, thesis, a schema from our CRIS, and a local schema for miscellaneous fields we wanted to store…), we just transform it using xsl rules to whatever we want the harvesters to pick up. You can even use multiple contexts and/or metadata formats if different harvesters have different preferences.

 

Deborah

 

From: dspace-c...@googlegroups.com <dspace-c...@googlegroups.com> On Behalf Of Peter
Sent: Wednesday, April 10, 2024 10:56 PM
To: DSpace Community <dspace-c...@googlegroups.com>
Subject: Re: [dspace-community] Switching from "dc" to "dcterms" in DSpace

 

You don't often get email from ad...@ispan.edu.pl. Learn why this is important

 

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.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/67f6ede5-7aa9-4f39-b859-67fdc1c57fcbn%40googlegroups.com.

---

"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."

[Jorge Gustavo Spertino]

Hello,

I have read the contributions of all the participants and it has been very valuable, thank you.

I have seen many of my thoughts reflected. I just want to restate something that Deborah mentioned.

Many of us who use DSpace are or aspire to be harvested or to harvest as the case may be. In this sense, it may be important to take into account the OAI-PMH protocol.

If you have the knowledge and dedication to carry out the mappings that Deborah refers to, such a situation can be resolved, otherwise, in my opinion, it would not be too advisable to deviate from dc, at least from the basic core, to guarantee a semi-direct passage.

Best,

Jorge

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/ME3PR01MB75242B3200E050A3E0875B5AC5052%40ME3PR01MB7524.ausprd01.prod.outlook.com.

[Peter]

Maybe future DSpace releases could include UI tool which would allow for a "schema to interface" (and other modules if necessary) items mapping? I imagine this could make DSpace more flexible in terms of schemas used. I found a similar tool while setting up collections in WorldCat Digital Collection Gateway.

Anyway, thank you all for your valuable comments.

Peter