search

DSpace / dspace-angular

DSpace User Interface built on Angular.io
https://wiki.lyrasis.org/display/DSDOC8x/
BSD 3-Clause "New" or "Revised" License
124 stars 415 forks source link

Creating a Resource Type entity based on COAR Resource Types 3.0 #1645

Open pilasou opened 2 years ago

pilasou commented 2 years ago

Objective

To offer a standardized alternatives to the default resource types in DSpace using the configurable entity model.

COAR Resource Types 3.0 Controled Vocabulary (https://vocabularies.coar-repositories.org/resource_types/) will be used for standardization.

So far, this vocabulary has already been implemented using DSpace Control Authority either sing an XML file or value pairs.

COAR Resource Types can be implemented using the Configurable entities model. This would allow institutions to use a common and standardized way to represent resource type.

The COAR Resource type vocabulary is mandatory in OpenAIRE for Resource Types.

Resource Type relationship resourceTypeRelation

New Metadata registry prefix for COAR Resource types vocabulary

Name | NameSpace -- | -- ResourceTypes | http://purl.org/coar/resource_type/

Metadata elements:

preferredLabels and alternateLabels in COAR are used for multilingualism. The language implemented can be specified using the metadata language qualifier in DSpace.

How to enter values and choose which preferredLabels or alternateLabels to use will left to each DSpace administrator.

Example for Research Article https://vocabularies.coar-repositories.org/resource_types/c_2df8fbb1/  

Metadata | Lang | Value -- | -- | -- ResourceTypes.uri |   | https://vocabularies.coar-repositories.org/resource_types/c_2df8fbb1/ ResourceTypes.definition | en | A research article is a primary source, that is, it reports the methods and results of an original study performed by the authors. (adapted from http://apus.libanswers.com/faq/2324) ResourceTypes.broaderConcepts | en | journal article ResourceTypes.name | en | research article ResourceTypes.preferredLabels | es | artículo original […] |   |   ResourceTypes.alternateLabels | fr | article de recherche ResourceTypes.alternateLabels | es | articulo cientifico […] |   |  

Impacted configurations and UI pages

Current plans include additional configurations in RelationshipTypes.xml, virtual-metadata.xml, submission-forms.xml and item-submission.xml. The functionality will be translated in French and English in the corresponding .json5 language files (en and fr). We also plan to add an additional custom item page in the angular project to display the resource type entity and adapt the relationship lookup search page.

Relationship lookup page type-lookup

Item Page item-page

The Item page design will be inspired by the COAR resource type page (below). coar-itempage

irynakuchma commented 2 years ago

Thank you Pierre, looks great and will be a very useful feature to include in the DSpace core.

pgwillia commented 2 years ago

How does this compare to the flexible data model in DSpace-CRIS?

pilasou commented 2 years ago

Hi @pgwillia, hum, I am not sure how it compares to this model. DSpace-CRIS is an independant product adding specific features not provided by DSpace. One thing for sure, when we design this new resource type entity, we did not have it in mind. Is there something in this proposal that DSpace-CRIS is already offering?

mhvezina commented 2 years ago

Upvote

tdonohue commented 1 year ago

Moving this ticket to our "unscheduled backlog" for now.

At this time, based on discussions in the DSpace 7 Development meetings, we feel any new Entity Types should be approved by DSpace Steering / Leadership before they can be added to DSpace.

In other words, we feel DSpace 7 development has been tightly scoped to only the initial set of Entity Types. So, while we can include enhancements/improvements specific to those initial Entity Types, we cannot add additional Entity Types until they are formally discussed and approved by Steering / Leadership. I'm not currently sure whether that would occur for DSpace 7, or if it'd need to wait for DSpace 8.

In any case, this ticket & the PRs will remain open for anyone wanting to use it. It just cannot be moved forward into the codebase until more discussion & prioritization occurs.

paulo-graca commented 7 months ago

Addressing the Resource Type as entities is one approach, a little more complex IMHO. We are addressing it differently. We choose to use Controlled Vocabularies at the submission form with the COAR supplied file (there is one for each supported language): DSpace XML Vocab file (Portuguese) to store values.

The biggest issue with this approach is that, at the frontend and by default, there aren't translations for vocabularies. We need to address them by creating or changing angular components. To me, this is a fault or issue with Controlled Vocabularies, we should consider and store the Vocabulary Node ID (c_12cc):

<node id="c_12cc" label="material cartográfico">

Perhaps like an authority value. Then we could use that authority value to do the translations since it's unique. It would be a better approach instead of using the label for it.

paulo-graca commented 7 months ago

Our solution is shown to the user in this way: image

pilasou commented 7 months ago

Hi @paulo-graca, I think I understand the alternative your are proposing. It builds on DSpace Authority Control File (XML) that existed in DSpace 6. This is how we have implemented COAR Resource Type in the 1st place. It reproduces the hierarchy but in its current form cannot represent the multilinguism and maintenance of the vocabulary is difficult (.i.e changes in terms, etc.). By using entities, we were trying to address those limitations and bring (some) solutions to implement multilinguism (the Type item contains all the translations in specific metadata) and simplify maintenance (thanks to virtual metadata) but were not able to reproduce the Heararchy (there is no hierarchical representation of the type by each type has metadata to identify broader [resourcetypes.broaderConcepts] or narrower [resourcetypes.broaderConcepts] terms). We have implemented the resourceType entity in ourown repository, here is link to the Document Type Collection: http://hdl.handle.net/20.500.11794/74204.

paulo-graca commented 3 months ago

@pilasou our solution (currently implemented) is based on controlled vocabularies and I think with this DS8 PR https://github.com/DSpace/DSpace/pull/9318 you will be able to address translations with a specific translated xml file.