Curation walk through

[Toby O at UWS]

Hey everyone, 

I'd like to organise a walk through of the curation process that is built into ReDBox, with an emphasis on the NLA-ID component where the Mint passes records to Trove/NLA and receives an NLA-ID back. I'm interested in what ReDBox/Mint does out of the box, and the minimum configurations that are required to get NLA integration working. I'm posting in ReDBox Dev, as I would like this to be a fairly technical discussion, relevant to the code and what code does what functions. Important to note: if anyone has rewritten the code with major customisations, and is having trouble, that's for a separate discussion.

I've spoken with Duncan who says that QCIF are happy to walk through it. Anyone who is interested should participate, I think would make the session more efficient, as in one explanation reaching lots of ears. Even if you've done this before, it might be worth joining in the conversation and adding tips and pointers that you have experienced yourself (UoN looking at you).  I'm shooting for the week of 10 Dec. I know that I won't be able to accommodate everyone's schedule, but if you'd like to join could you take a moment and mark your preferred times on Doodle http://www.doodle.com/e5id78sh3g9x5yp7 

Cheers, 

Toby

[Toby at UWS]

Just a follow up, thanks to everyone who responded to the Doodle poll - and apologies to those who can't make the allotted time. Looks like most are able to do Tues 11 Dec 12-2 pm Sydney time.  Email me if you would like to get the GoTo meeting details. Space is limited, so it's first come first serve.

Cheers,
Toby

[Duncan Dickinson]

Hi All,

I've prepared a presentation to help guide my overview: https://docs.google.com/open?id=0B2ekIO0v2A7CTVRlVlRLb2ZINlk

It's also linked from our doco: http://www.redboxresearchdata.com.au/documentation/system-overview/curating-linked-data

I'll also discuss the issues raised around NLA Trove pointing back to your Mint install - I have some thoughts on a solution that I'd like to get feedback on.

Looking forward to it - please feel free to mail the list with any questions/issues you want discussed - replying to this thread would be a good idea.

Thanks to Toby for getting this together. Toby has also posted a workflow chart to the user mailing list that will help the discussions: https://groups.google.com/d/topic/redbox-repo/-nGTI7wUWXM/discussion

Cheers,

Duncan

[Toby O at UWS]

Thanks Duncan good stuff.

Looking forward to tomorrow as well.

If there is anyone who does not have the details of the meeting who would like to join, please get in touch with me. 

Cheers, 

Toby

[Toby at UWS]

Hi All,

At the risk of boring everyone, I'm going to provide my notes on the meeting. There was a lot discussed, I haven't tried to capture all of it, and please don't take this as gospel, if anything it's more of a hint as to how far off base I probably am.

Notes

Because it was a first go on the topic we spent a little bit of time on the basics (such as keys, identifiers, and links) just to be sure that the foundation was set before diving into what curating a record in ReDBox actually means.

My take away was that curation in ReDBox basically finalises a record by asking Mint to:

·         Get a unique identifier, in the form of a (internally or externally) resolvable handle for PARTY (person), PARTY (group), SERVICE (if applicable), and the COLLECTION. This provides for linked data, so that each unique handle will be linked going forward (in our discussion we assumed that the university is using a handle service).

·         Get an NLA Identifier by creating a PARTY record in EAC-CPF and exposing it to Trove for harvest. (there’s a bit of murk at this point, but ANDS have some helpful materials here) and then Mint starts pinging for a match on Local ID (which was sent in the EAC-CPF record), where an NLA ID has been created. When a match is found, the PARTY record is updated with a value in the NLA ID field.

When ReDBox gets the all clear from Mint, it can then create the RIF-CS record and expose it to RDA.

Of course this summary is not meant to replace a thorough read of the documentation, there are plenty of specifics, nuances and options that I have glossed over which you (technical folk) will need to know when implementing your build at your campus.

We had some technical discussion as well and looked at code. For example. We looked at the code that makes a new EAC-CPF record. Out of the box, it is minimal (fname, lname, description) and your university has to decide if a richer record would be preferred for NLA to have and to hold. If the answer is yes, then the json would have to be expanded.

It was also reiterated a few of the issues that have been noted with using NLA as a name authority:

·         If you want to send PARTY (groups) to NLA, it does not show up. NLA will attribute a record to an organisation such as a university, but does not appear to be set up to display what group, such as a School of Engineering, or Centre for Assiduous Academics, to which the individual belongs (or belonged).

·         The location of the PARTY (person) is not displayed; sending location across in the correct EAC-CPF field isn't displayed on the website.

·         When viewing a PARTY (person) record on the NLA/Trove site, a description below the person’s details includes a link back to the source, and that link could be a dead link, especially if it was assigned a non-resolvable URI or handle, or the link goes to a firewalled instance of Mint, or the link goes to a staff page for a staff member who has moved on. There are several options to fix this, however, none of them appear to be low maintenance nor easy. This would of course require some careful planning and decision making in order to implement a working solution.

Best,

Toby