- Fix a reference to `dc.type.output` in Discovery that I had missed when we migrated to `dc.type` last month ([#223](https://github.com/ilri/DSpace/pull/223))
![Item type in Discovery results](../images/2016/05/discovery-types.png)
- There are lots of fields in `dcterms` namespace that look interesting, like:
- dcterms.type
- dcterms.spatial
- Not sure what `dcterms` is...
- Looks like these were [added in DSpace 4](https://wiki.duraspace.org/display/DSDOC5x/Metadata+and+Bitstream+Format+Registries#MetadataandBitstreamFormatRegistries-DublinCoreTermsRegistry(DCTERMS)) to allow for future work to make DSpace more flexible
- Start a test rebase of the `5_x-prod` branch on top of the `dspace-5.5` tag
- There were a handful of conflicts that I didn't understand
- After completing the rebase I tried to build with the module versions Atmire had indicated as being 5.5 ready but I got this error:
```
[ERROR] Failed to execute goal on project additions: Could not resolve dependencies for project org.dspace.modules:additions:jar:5.5: Could not find artifact com.atmire:atmire-metadata-quality-api:jar:5.5-2.10.1-0 in sonatype-releases (https://oss.sonatype.org/content/repositories/releases/) -> [Help 1]
- Turns out she was able to decrease the size of the PDF so we didn't have to do anything
## 2016-05-12
- Looks like the issue that Abenet was having a few days ago with "Connection Reset" in Firefox might be due to a Firefox 46 issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1268775
- I finally found a copy of the latest CG Core metadata guidelines and it looks like we can add a few more fields to our next migration:
- dc.rplace.region → cg.coverage.region
- dc.cplace.country → cg.coverage.country
- Questions for CG people:
- Our `dc.place` and `dc.srplace.subregion` could both map to `cg.coverage.admin-unit`?
- Should we use `dc.contributor.crp` or `cg.contributor.crp` for the CRP (ours is `dc.crsubject.crpsubject`)?
- Our `dc.contributor.affiliation` and `dc.contributor.corporate` could both map to `dc.contributor` and possibly `dc.contributor.center` depending on if it's a CG center or not
-`dc.title.jtitle` could either map to `dc.publisher` or `dc.source` depending on how you read things
- Found ~200 messed up CIAT values in `dc.publisher`:
```
# select text_value from metadatavalue where resource_type_id=2 and metadata_field_id=39 and text_value similar to "% %";
-`dc.place` is our own field, so it's easy to move
- I've removed `dc.title.jtitle` from the list for now because there's no use moving it out of DC until we know where it will go (see discussion yesterday)
- More quality control on `filename` field of CCAFS records to make processing in shell and SAFBuilder more reliable:
```
value.replace('_','').replace('-','')
```
- We need to hold off on moving `dc.Species` to `cg.species` because it is only used for plants, and might be better to move it to something like `cg.species.plant`
- And `dc.identifier.fund` is MOSTLY used for CPWF project identifier but has some other sponsorship things
- We should move PN*, SG*, CBA, IA, and PHASE* values to `cg.identifier.cpwfproject`
- The rest, like BMGF and USAID etc, might have to go to either `dc.description.sponsorship` or `cg.identifier.fund` (not sure yet)
- There are also some mistakes in CPWF's things, like "PN 47"
- This ought to catch all the CPWF values (there don't appear to be and SG* values):
```
# select text_value from metadatavalue where resource_type_id=2 and metadata_field_id=75 and (text_value like 'PN%' or text_value like 'PHASE%' or text_value = 'CBA' or text_value = 'IA');