- Looking at the CG Core document again, I'll send some feedback to Peter and Abenet:
- We use cg.contributor.crp to indicate the CRP(s) affiliated with the item
- DSpace has dc.date.available, but this field isn't particularly meaningful other than as an automatic timestamp at the time of item accession (and is identical to dc.date.accessioned)
- dc.relation exists in CGSpace, but isn't used—rather dc.relation.ispartofseries, which is used ~5,000 times to Series name and number within that series
- Also, I'm noticing some weird outliers in `cg.coverage.region`, need to remember to go correct these later:
```
dspace=# select text_value from metadatavalue where resource_type_id=2 and metadata_field_id=227;
- Trying to find a way to get the number of items submitted by a certain user in 2016
- It's not possible in the DSpace search / module interfaces, but might be able to be derived from `dc.description.provenance`, as that field contains the name and email of the submitter/approver, ie:
```
Submitted by Francesca Giampieri (fgiampieri) on 2016-01-19T13:56:43Z^M
- This SQL query returns fields that were submitted or approved by giampieri in 2016 and contain a "checksum" (ie, there was a bitstream in the submission):
```
dspace=# select * from metadatavalue where resource_type_id=2 and metadata_field_id=28 and text_value ~ '^(Submitted|Approved).*giampieri.*2016-.*checksum.*';
```
- Then this one does the same, but for fields that don't contain checksums (ie, there was no bitstream in the submission):
```
dspace=# select * from metadatavalue where resource_type_id=2 and metadata_field_id=28 and text_value ~ '^(Submitted|Approved).*giampieri.*2016-.*' and text_value !~ '^(Submitted|Approved).*giampieri.*2016-.*checksum.*';
```
- For some reason there seem to be way too many fields, for example there are 498 + 13 here, which is 511 items for just this one user.
- It looks like there can be a scenario where the user submitted AND approved it, so some records might be doubled...
- In that case it might just be better to see how many the user submitted (both _with_ and _without_ bitstreams):
- After reading the [notes for DCAT April 2017](https://wiki.lyrasis.org/display/cmtygp/DCAT+Meeting+April+2017) I am testing some new settings for PostgreSQL on DSpace Test:
- Looking at the [documentation](https://wiki.lyrasis.org/display/DSDOC5x/XMLUI+Configuration+and+Customization) it seems that we probably want to be using DSpace Intermediate Metadata
- CIFOR is starting to test aligning their metadata more with CGSpace/CG core
- They shared a [test item](https://data.cifor.org/dspace/xmlui/handle/11463/947?show=full) which is using `cg.coverage.country`, `cg.subject.cifor`, `dc.subject`, and `dc.date.issued`
- Looking at their OAI I'm not sure it has updated as I don't see the new fields: https://data.cifor.org/dspace/oai/request?verb=ListRecords&resumptionToken=oai_dc///col_11463_6/900
- Maybe they need to make sure they are running the OAI cache refresh cron job, or maybe OAI doesn't export these?
- I added `cg.subject.cifor` to the metadata registry and I'm waiting for the harvester to re-harvest to see if it picks up more data now
- Another possiblity is that we could use a cross walk... but I've never done it.
## 2017-04-11
- Looking at the item from CIFOR it hasn't been updated yet, maybe they aren't running the cron job
- Side note: WTF, I just saw an item on CGSpace's OAI that is using `dc.cplace.country` and `dc.rplace.region`, which we stopped using in 2016 after the metadata migrations:
- The particular item is [10568/6](http://hdl.handle.net/10568/6) and, for what it's worth, the stale metadata only appears in the OAI view:
OAI 2.0 manager action ended. It took 829 seconds.
```
- After reading some threads on the DSpace mailing list, I see that `clean-cache` is actually only for caching _responses_, ie to client requests in the OAI web application
- These are stored in `[dspace]/var/oai/requests/`
- The import command should theoretically catch situations like this where an item's metadata was updated, but in this case we changed the metadata schema and it doesn't seem to catch it (could be a bug!)
OAI 2.0 manager action ended. It took 1032 seconds.
real 17m20.156s
user 4m35.293s
sys 1m29.310s
```
- Now the data for 10568/6 is correct in OAI: https://cgspace.cgiar.org/oai/request?verb=GetRecord&metadataPrefix=dim&identifier=oai:cgspace.cgiar.org:10568/6
- Perhaps I need to file a bug for this, or at least ask on the DSpace Test mailing list?
- I wonder if we could use a crosswalk to convert to a format that CG Core wants, like `<date Type="Available">`
- Checking the [CIFOR item on DSpace Test](https://dspacetest.cgiar.org/handle/11463/947?show=full), it still doesn't have the new metadata
- The collection status shows this message from the harvester:
> Last Harvest Result: OAI server did not contain any updates on 2017-04-13 02:19:47.964
- I don't know why there were no updates detected, so I will reset and reimport the collection
- Usman has set up a custom crosswalk called `dimcg` that now shows CG and CIFOR metadata namespaces, but we can't use it because DSpace can only harvest DIM by default (from the harvesting user interface)
- Also worth noting that the REST interface exposes all fields in the item, including CG and CIFOR fields: https://data.cifor.org/dspace/rest/items/944?expand=metadata
- This allows us to have, say a default "request" context and a "cgiar" context, both of which implement the DSpace Intermediate Metadata formats, but have the later use a overridden version that exposes CG metadata
- CIFOR has now implemented a new "cgiar" context in their OAI that exposes CG fields, so I am re-harvesting that to see how it looks in the Discovery sidebars and searches
- One thing we need to remember if we start using OAI is to enable the autostart of the harvester process (see `harvester.autoStart` in `dspace/config/modules/oai.cfg`)
- This is interesting for creating runnable commands from `bundle`:
```
$ bundle binstubs puma --path ./sbin
```
## 2017-04-19
- Usman sent another link to their OAI interface, where the country names are now capitalized: https://data.cifor.org/dspace/oai/cgiar?verb=GetRecord&metadataPrefix=dim&identifier=oai:data.cifor.org:11463/947
- Looking at the same item in XMLUI, the countries are not capitalized: https://data.cifor.org/dspace/xmlui/handle/11463/947?show=full
- So it seems he did it in the crosswalk!
- Keep working on Ansible stuff for deploying the CKM REST API
- We can use systemd's `Environment` stuff to pass the database parameters to Rails
- Atmire responded about the Workflow Statistics, saying that it had been disabled because many environments needed customization to be useful
- I re-enabled it with a hidden config key `workflow.stats.enabled = true` on DSpace Test and will evaluate adding it on CGSpace
- Looking at the CIAT data again, a bunch of items have metadata values ending in `||`, which might cause blank fields to be added at import time
- Cleaning them up with OpenRefine:
```
value.replace(/\|\|$/,"")
```
- Working with the CIAT data in OpenRefine to remove the filename column from all but the first item which requires a particular PDF, as there are many items pointing to the same PDF, which would cause hundreds of duplicates to be added if we included them in the SAF bundle
- I did some massaging in OpenRefine, flagging duplicates with stars and flags, then filtering and removing the filenames of those items
- Also there are loads of whitespace errors in almost every field, so I trimmed leading/trailing whitespace
- Unbelievable, there are also metadata values like:
- Someone on the dspace-tech mailing list responded with a suggestion about the foreign key violation in the `cleanup` task
- The solution is to remove the ID (ie set to NULL) from the `primary_bitstream_id` column in the `bundle` table
- After doing that and running the `cleanup` task again I find more bitstreams that are affected and end up with a long list of IDs that need to be fixed:
```
dspace=# update bundle set primary_bitstream_id=NULL where primary_bitstream_id in (435, 1136, 1132, 1220, 1236, 3002, 3255, 5322);
- Now running the cleanup script on DSpace Test and already seeing 11GB freed from the assetstore—it's likely we haven't had a cleanup task complete successfully in years...
