Back to the main page.
Bug 2484 - implement ft_deidentifydata function for anonimization purposes of fieldtrip data structures
| Status | CLOSED FIXED |
| Reported | 2014-02-26 15:10:00 +0100 |
| Modified | 2014-05-14 20:08:51 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 481 |
| See also: |
Robert Oostenveld - 2014-02-26 15:10:39 +0100
It only needs to work on data.cfg and all substructures, searching for fields that contain strings. Fields with numeric values are not identifying. Fieldnames are not identifying. It should have cfg.inputfile cfg.outputfile cfg.keep = {} cfg.remove = {} cfg.uncertain = 'ask', 'error' The output data.cfg should maintain provenance and keep track using cfg.deidentified = {} with a list of all fields whose value was deidentified.
Robert Oostenveld - 2014-03-18 12:31:04 +0100
I implemented a first version mbp> svn commit ft_deidentifydata.m ft_examplefunction.m utilities/private/smartinput.m Adding ft_deidentifydata.m Sending ft_examplefunction.m Sending utilities/private/smartinput.m Transmitting file data ... Committed revision 9295.
Robert Oostenveld - 2014-03-18 13:15:14 +0100
I demonstrated it to Tineke and discussed it with her. Some problems encountered/realized: - data.cfg.previous can be a cell-array - fields can be a struct-array, like data.cfg.event - data.hdr.orig is also potentially identifiable Right now the function maintains two lists: keep and remove, and one option for realing with unknown fields (i.e. usually ask). When asking, it prints Should this field be (k)ept, (r)emoved, [K]eep all, [R]emove all? better is to implement it as [k]eep the field this time only, ask again for the next occurrence [r]emove the field this time only, ask again for the next occurrence [K]eep the field from now on, don't ask again [R]emove the field from now on, don't ask again The consequence of k and r would be that it is placed on the "ask" list, i.e. rather than having a cfg.uncertain option with string values, it should have three lists: keep, remove and ask.
Robert Oostenveld - 2014-04-07 11:46:17 +0200
I added the first implementation to svn, although there is still work to be done on it. mac011> svn commit ft_anonimizedata.m Adding ft_anonimizedata.m Transmitting file data . Committed revision 9367. mac011> svn commit ft_anonimizedata.m ft_deidentifydata.m Sending ft_anonimizedata.m Deleting ft_deidentifydata.m Transmitting file data . Committed revision 9368.
Robert Oostenveld - 2014-04-07 22:58:44 +0200
mac011> svn commit ft_anonimizedata.m Sending ft_anonimizedata.m Transmitting file data . Committed revision 9376. Major rewrite of core functionality, added a tabular GUI to get an improved overview. The function seems to be working as expected and removes the desired fields. The only thing that I feel remains to be done is to ask for end-user feedback and incorporate that in the help. In the mean time, I'll be able to use it as it is.
Arjen Stolk - 2014-04-07 23:14:35 +0200
(In reply to Robert Oostenveld from comment #4) Nice work!