Skip to main content

Zoom Logo

IAM Online - August 2018 - Shared screen with speaker view
Dean Woodbeck
26:16
Please enter your questions here as you think of them!
Dean Woodbeck
30:28
FYI — the slide deck is available as a PDF at www.incommon.org/iamonline
Jeremy Rosenberg
36:04
Yes
Nick Roy
36:08
@BennO, why the move from in-memory to use of an RDBMS for the UCB PoC?
Nick Roy
36:15
(or @Summer)
Benn Oshrin
37:15
Basically in memory ran into synchronization and “reinventing the wheel” issues. It turns out to be a lot simpler to just let an RDBMS due searching, since it’s way more optimized than any custom code we might right
Benn Oshrin
37:17
write
Benn Oshrin
37:37
The match engine just becomes a glorified API-to-SQL translator
Nick Roy
38:03
Thanks! I wondered about synchronizing in-memory. Also wondered if throughput might be enough of a bottleneck to have influenced the original choice of in-memory.
Benn Oshrin
38:58
i don’t recall throughput being an issue back then…
Nick Roy
39:12
(thumbs up)
Jeremy Rosenberg
40:17
shopped
Benn Oshrin
41:19
I’ll talk about this for the TIER product later, but initial is distance and substring. More to be added in subsequent versions.
Kristi Wall
42:54
Who all do you use for the human review. Functional units like HR or IT?
sattleba
43:38
Do you have any control/input over SOR systems and how users interact to input their data? Such as UTF standards, legal name vs preferred name being entered, name lengths, suffix data
Andrew Hughes
43:52
Does the tool allow de-matching to reverse matching errors?
Nick Roy
43:58
How are "DISTANCE" matches calculated? Soundex or ... ?
Jeremy Rosenberg
44:20
Calnet team does manual reviews, usually our students.
Benn Oshrin
44:32
“Distance” is basically a diff. So NICK and NCIK has a distance of 2
Jeremy Rosenberg
45:07
We control how we injest data from SOR systems and we have to do any translation that’s needed for our matching purposes.
Jeremy Rosenberg
45:21
The tool does do “split” the reverse of match.
Jeremy Rosenberg
48:43
Ya, I’m only seeing part of this conversation :)
sattleba
48:43
Has anyone tried matching tables? Equating Robert=Bob=Roberto...?
jeaton
48:50
If something has no exact and no potential matches, does it automatically generate a new BPR entry?
Dan Malone - Cal Poly SLO
48:54
On average, how many records land in your potential match queue over a year?
Jeremy Rosenberg
49:10
Yes, no exact and no potential means new UID and provision.
Lisa C.
52:12
Any thought on how feasible it is to create rules to do the investigation/reconciliation instead of needing a human to make an assessment?
sattleba
52:39
I looked years ago and someone sells a database of similar names
sattleba
52:48
In different languages as well
Andrew Hughes
52:59
How many rules are there? (how much effort to manage the rules)
Jeremy Rosenberg
53:11
I defer to Benn :) Does the Postgres filters handle names?
Benn Oshrin
53:36
More in Part III :)
Benn Oshrin
54:53
TO PANELISTS: Dave Bartholomew got a question into the Q&A window, maybe we can get to it after part III
jeaton
56:15
Only 3 out of 50K resulted in incorrect matches, do you have a estimate on how many matches failed to find the right person (neither exact nor approximate generated a hit, so you end up with duplicate entries that are later caught)?
Jeremy Rosenberg
57:40
We actually watch closely for those and I don’t believe we’ve found any duplicates since this code was put in place. We do still find duplicates but both records were created by legacy provisioning tools.
Summer Scanlan
59:19
We’ve had a handful of dupes that were created since we implemented BPR. Too few to diagnose the problem so far! Most consolidations of duplicate accounts are dupes created by SORs, and dupes created by our old Sync Code.
Summer Scanlan
59:32
We’ve had a handful of dupes that were created since we implemented BPR. Too few to diagnose the problem so far! Most consolidations of duplicate accounts are dupes created by SORs, and dupes created by our old Sync Code.
Lisa C.
01:00:06
Obtaining a list of your matching rule data points would likely be useful to folks, whether authoritative or ‘secondary’ matches. We’re always looking to improve our matching techniques, and are interested especially in
Lisa C.
01:00:17
common data points found in varying SORs
Dean Woodbeck
01:12:27
Please take a couple of minutes and complete our evaluation of this webinar. We’re also interested (and there is a spot) for ideas on future webinars. https://www.surveymonkey.com/r/IAMOnline-Aug2018
Jeremy Rosenberg
01:13:52
Individually for sure, maybe not published.
Dean Woodbeck
01:14:12
sscanlan@berkeley.edu
Nick Roy
01:15:47
Awesome panel!
Nick Roy
01:15:52
Thanks Keith, Summer and Benn!
Benn Oshrin
01:16:03
Thanks everyone!