Problem when activating dropdown for dc.subject with controlled vocabulary

[Javi Rojo Díaz]

Good morning, 

I am having a problem when I activate the controlled vocabulary. The issue is that when I select a subject within the subject tree, DSpace considers everything as a single subject and stores them in a single dc.subject.

In this case, the behavior we want is that, when selecting a sub-subject, all the subjects traversed to reach that sub-subject should be stored in separate dc.subject fields, appearing in the full item view as:

dc.subject - Matemáticas

dc.subject - Geometría

dc.subject - Fundamentos

We also see that in the search filters and facets, this combined dc.subject appears, and the behavior is not appropriate:

Is there any way to use this subject dropdown so that each selected subject is stored in separate dc.subject fields? 

Thank you very much and best regards.

[DSpace Technical Support]

Hi,

At this time, this is the expected behavior in DSpace.  Hierarchical subject terms are always stored in a single field (with values separated by double colons).  However, the individual values are still browseable/searchable using the "Browse by Subject Category" feature (under the "All of DSpace" menu), or the "Browse Subject Tree" in the Search facets.

I'm not aware of a way to store these values in separate fields, as it'd likely break the current hierarchical browse/search functionality.

That said, if anyone out there has found a way to achieve this behavior, hopefully they'll share it on this thread.

Tim

[Javi Rojo Díaz]

Hello Tim,

Thank you for your response. After several attempts to separate the `dc.subject` into independent `dc.subjects` based on the "::" separator, we finally managed to do it by running an SQL query that checks if any `dc.subject` contains the "::" separator. If so, it splits them into independent `dc.subjects` within the same item.

I am attaching a script that should be configured in the crontab to keep checking and adjusting the `dc.subject` fields. Additionally, the script stores the IDs of the items whose `dc.subject` fields have been split and runs a reindexation for each item. (Without reindexing, the filters and facets would still show the unified `dc.subject` with "::". I perform item-level reindexing to avoid executing a full reindexing, which could overload the machine and DSpace.)

I wanted to configure this as a trigger, but it was completely impossible. When creating the item, the trigger wouldn’t start and execute the query, so I ultimately configured it using an SQL query + crontab.

I already have it in production, and it is working correctly. However, I recommend testing it on a test item by adding a new condition to the SQL query.

I hope this is useful for someone.

 

Many thanks and best regards