Mint 1.8: updating records and handle creation

[Katrina Trewin]

Hi everyone,

We recently moved to ReDBox / Mint 1.8 and are in the process of updating our Mint records due to our recent institutional name change.

We are using a method whereby we are uploading our csv file which uses the existing researcher ID for the updated record, and also lists the ID appended with _1 for the original record, so that we have a curatorial link back to the original record.

For parties that already have a handle identifier, which has been produced during curation of an associated ReDBox record, we have added the handle value in the URI column of the csv. 

Anyway - we have found when testing this in dev environment that when we associate a new ReDBox record with these parties, it either creates a brand new handle (still listing the old one under known IDs) or goes ahead and uses the existing handle. If it produces a new one, it then uses this one for any further records.

The difference seems to be that parties added to the Mint after we moved to 1.8 are producing new ones, those that have been around for the long haul do not.

If you can provide any insight or experience into this, we'd appreciate the input.

We are not overly worried about the additional handle, although it creates additional workflow and checking considerations, but it is interesting that the older records don't produce the additional identifier.

Many Thanks,

Katrina

Katrina Trewin | Research Data Coordinator

Library

P: 9852 5892

 

westernsydney.edu.au

 

[Andrew Brazzatti]

Hi Katrina,

The curation process that gets triggered off when a data collection record is published will check Mint to see if the related party records are already curated and if not have Mint go off and get a handle for the party before returning that value to ReDBox.

The way Mint determines whether a record is curated or not is a bit more involved than whether it has a handle value in the metadata so most likely the issue is that it's missing some of those additional attributes. If you have a look at the TF-OBJ-META files of one of the "working" party records (you can find this in the "Attachments" section of the details page of a record) compared to one that is curating a new handle, there will most likely be some differences (no published=true and potentially not a handlePid= value).

Thanks,

Andrew

--
-- Website: http://www.redboxresearchdata.com.au
 
You received this message because you are subscribed to the Google Groups ReDBox group. To post to this group, send email to redbo...@googlegroups.com. To unsubscribe from this group, send email to redbox-repo...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/redbox-repo?hl=en
---
You received this message because you are subscribed to the Google Groups "ReDBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redbox-repo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Grant Jackson]

Hi Katrina,

I haven't got this far with 1.8 yet. The info which follows might not be applicable to you however since you've upgraded Mint and changed institutional name I thought I'd mention a trap I fell into a few years ago. The gist of it is that Mint uses a compound key for each record which consists of:

 - ID field on CSV record
 - recordIDPrefix from json config (eg. home/harvest/Parties_People.json or whatever yours is called)
 - CSV filename (& maybe other things)

So if that compound key has any differences from a previous harvest (eg. the CSV filename or recordIDPrefix has changed) you will get a *new* Mint record. Some more info is at https://groups.google.com/forum/#!searchin/redbox-repo/recordIDPrefix$20grant/redbox-repo/rbOCjOs-dFM/8BWGvuE83tsJ

Hopefully my info isn't out of date! Hope this helps.

Cheers, Grant

[Katrina Trewin]

Thanks Andrew,

Here is what I found when I checked the TF-OBJ-META:

Record for Craig Barton (new)  - retained a previous handle upon curation of new associated RB record:

#The Fascinator Indexer Metadata

#Mon Nov 30 17:30:07 EST 2015

objectId=c386012db1fdadfa011c46e9d8c3f2de

scriptType=python

userPriority=true

render-pending=false

IngestedRelationshipsTransformer=hasRun

jsonConfigPid=Parties_People.json

repository.name=People

rulesPid=Parties_People.py

nlaPid=http\://nla.gov.au/nla.party-1508448

repository.type=Parties

eac_creation_date=2013-05-01T06\:07\:01Z

date_object_created=2015-06-15T16\:11\:46Z

metaPid=TF-OBJ-META

jsonConfigOid=05f571708b8ec97e54ec53b61af7df59

ready_to_publish=ready

rulesOid=7a09bd065f412f8c82e8f440ff7a46d4

handle=http\://handle.uws.edu.au\:8081/1959.7/512163

published=true

ready_for_nla=ready

Record for Mathias Boer (new) – created a new handle upon curation of new associated RB record:

#The Fascinator Indexer Metadata

#Mon Nov 30 17:06:55 EST 2015

objectId=0a26a05c9dacadf40970243c7ea90d0c

scriptType=python

render-pending=false

IngestedRelationshipsTransformer=hasRun

jsonConfigPid=Parties_People.json

repository.name=People

rulesPid=Parties_People.py

nlaPid=http\://nla.gov.au/nla.party-1599137

repository.type=Parties

eac_creation_date=2015-11-29T22\:59\:08Z

date_object_created=2015-06-03T11\:41\:16Z

metaPid=TF-OBJ-META

jsonConfigOid=05f571708b8ec97e54ec53b61af7df59

ready_to_publish=ready

rulesOid=7a09bd065f412f8c82e8f440ff7a46d4

handle=http\://handle.uws.edu.au\:8081/1959.7/531982

published=true

ready_for_nla=ready

The only difference seems to be that the 'working record' has an additional line: userPriority=true

Are you able to shed some light on this difference, and how we might address it?

I gather it's a difference in the config between our previous version of Mint and this 1.8 instance?

[Katrina Trewin]

Thanks Grant :) I think we have that part happening ok, but will keep it in mind.

[Katrina Trewin]

Many Thanks,

Katrina

Katrina Trewin | Research Data Coordinator

Library

P: 9852 5892

westernsydney.edu.au