Closed alanorth closed 5 years ago
Dear @marieALaporte,
Did you have time to review my comments and suggestions? I've discussed these notes with Abenet as well as the MELSpace guys at ICARDA. We are ready to start doing implementation tests on CGSpace. Let me know what you think. We can chat on Skype this coming week if you like?
Thanks!
as agreed during our discussion with @alanorth:
- Suggest CG Core add DCTERMS.extent because it is vanilla DCTERMS and covers pages, chapters, etc, and refines DCTERMS.format
agredd, will add dct.extent . The MWG is going to decide if we need to remove elements like pages, ... or keep everything
- Suggest CG Core add DCTERMS.publisher because it is vanilla DCTERMS and there is no similar field in CG Core
agreed, will add dct.publisher
- Suggest CG Core add DCTERMS.issued because it is vanilla DCTERMS and CG Core currently only has DCTERMS.date
agreed, will replace dct.date by dct.issued as it is more specific and accurate to what we are trying to record
- Suggest CG Core add DCTERMS.description in favor of cg.notes because it is vanilla DCTERMS and seems appropriate (abstracts are already in DCTERMS.abstract)
keep cg.note if CGSpace needs to record notes, remove otherwise. dct.description is used to attach a description to information products so it is better not to use the same element in 2 different contexts.
- Suggest CG Core add a field to capture ISBNs and ISSNs. CGSpace is currently using cg.identifier.issn and cg.identifier.isbn
agreed, will add cg.issn and cg.isbn
Also, cg.peer-reviewed is going to take the value true is peer reviewed. The element won't appear is not peer reviewed. Will change the guidelines accordingly.
As the PR was merged, this can be closed
Dear @marieALaporte et al,
I've gone through the current CG Core metadata schema and updated my list of suggested metadata migrations for CGSpace to align better with the schema as well as made some observations and suggestions for CG Core—the list is getting slightly longer. I will summarize the suggestions here:
DCTERMS.extent
because it is vanilla DCTERMS and covers pages, chapters, etc, and refinesDCTERMS.format
DCTERMS.publisher
because it is vanilla DCTERMS and there is no similar field in CG CoreDCTERMS.issued
because it is vanilla DCTERMS and CG Core currently only hasDCTERMS.date
DCTERMS.description
in favor ofcg.notes
because it is vanilla DCTERMS and seems appropriate (abstracts are already inDCTERMS.abstract
)cg.identifier.issn
andcg.identifier.isbn
A note on the
DCTERMS
namespace: the DSpace platform uses a flat schema and the namespace is capitalized there, so I have done the same in all my notes. On that note, many DSpace fields aredc.xxx
and there are equivalents in DCTERMS, so I am assuming we will move them. Is this semantically correct or unnecessary bike shedding?Thank you!