Subjects changes

[Vensberg]

This issue has three parts:

1. The subjects that have narrower scope should show the people and works from that narrower scope. @wrenaria, please add and expand on this as you see fit.
2. Subjects that that don't have anything should not be shown at all
3. @qjhart and @Vensberg need to discuss what to do with the same subjects from different vocabularies.

[qjhart]

Currently, the Fields of Research, (FoR) are the only terms that are suffering from this problem. The issue is that we pull in the entire FoR database on data load. We now have added a vocabulary graph, that also holds FoR data. We should update the harvest method so that subjects (and their broader terms) are added as users and publications are added to the system. I've made a new issue for that piece.

Regarding the 2nd issue, showing all users for broader terms. I'm not sure what the best solution for this is in terms of indexing. @jrmerz do you think that the Elastic index queries should include all broader terms as well? That seems like the best solution, but they really can't be in the same field. For example, for https://dev.experts.ucdavis.edu/api/record/ucdrp:person/1f3604112472f3385058ed324bc4aa83, we want this member to come up in Chemical Sciences, since it's a broader term, but we don't want to add that as a hasResearchArea . Should we add something like hasBroaderResearchArea? Or were we thinking of an alternative solution?

[jrmerz]

The boarder term search has already been implemented. The model service has to ability to add 'private' (stored in a '_' property) attributes. This is where fields such as top20Citation and lastCitation are stored. These fields are indexed and searchable but never returned to the client. This is done during the post process step in model service.

Currently the model service sees if the object has hasSubjectArea or hasResearchArea and looks up all broader terms, storing in the _.allSubjectArea or _.allResearchArea fields/indexes. https://github.com/ucd-library/vessel/blob/main/es-models/default/post-process.js#L60. These indexes are then used when query for research for a specific subject: https://github.com/ucd-library/rp-ucd-client/blob/89676f33c5b1ebc40e39d1c0cc238f7d31f943a0/client/public/src/services/SubjectService.js#L81

[Vensberg]

For 3.

• Don't join vocabularies

[Vensberg]

Sounds like what's left is having researchers come up on the broader subject pages.

[Vensberg]

People who should be showing here https://dev.experts.ucdavis.edu/concept/FoR/09, but are not:

• https://rc.experts.ucdavis.edu/person/c16a4ff65bafbe8631a5f01cc127b2d7
• https://rc.experts.ucdavis.edu/person/4cb7395f61f2d4a0565220e7eb5c5f8f
• https://rc.experts.ucdavis.edu/person/b516ec8d5984b8f4a345af6d7f57280a

I can see that the existing list of 10 researchers includes some with only narrower subject terms. Is this a case of a missing "More" button?

[wrenaria]

Empty subject pages (# 2 in the original comment from Vessela) are causing confusion in user testing. Can we get pages without content (no researchers, no publications, etc) hidden in the near future, please?

[qjhart]

@wrenaria / @Vensberg part 2 of this is fixed in dev. Adding to rp. @Vensberg we should maybe close this and open one specifically for joining multiple controlled vocab subjects?

[Vensberg]

Looks good. I'll open an issue about joining vocabularies.