FEC ids aren't consistent for legislators about congress-legislators

[JoshData]

But at most one fec_id per term, right?

[jsfenfen]

Sadly no; bachman raised money both for her presidential bid and her house race this cycle. The campaign finance limits are applied per race, I think, so the system probably reflects that; one can max out to her as a house candidate and as a presidential candidate.

[konklone]

Sounds like the simplest solution is just to make this an array - all FEC IDs which can apply to this person. I don't think the complexity cost of doing many-to-many between FEC IDs and individual terms is going to be worth it, but we also clearly don't want to just exclude any FEC IDs from the system because they're weird sometimes.

[JoshData]

@jsfenfen, Oh er, sorry you said that the first time. :)

@konklone Sounds good. (An alternative would be to put the fec_id for House/Senate races only on the term, where it seems to be at-most-one (and the placement would also code the election cycle), and either ignore presidential fec_ids or put them as you're saying in a list on the person-level id node.)

[jsfenfen]

One could apply it retrospectively to terms, and only give each legislator
the FEC_ID for the seat they won.

On Tue, Nov 13, 2012 at 5:30 PM, Eric Mill [email protected] wrote:

Sounds like the simplest solution is just to make this an array - all FEC
IDs which can apply to this person. I don't think the complexity cost of
doing many-to-many between FEC IDs and individual terms is going to be
worth it, but we also clearly don't want to just exclude any FEC IDs from
the system because they're weird sometimes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-10346829.

[konklone]

We could do both? In the main "id" node, have an array of all FEC IDs, and then on each term, put all FEC IDs that were valid for them during that term. I actually wouldn't be bothered if a presidential FEC ID appeared on either their top-level or per-term lists.

[dwillis]

Couple of thoughts - if we do an array of FEC ids, would we update historic legislator files to include new IDs if they happen to win election after a period of not being in Congress? I agree that some kind of look-up is useful, but I wonder if that's a separate file or whether we need to have FEC history in the "id" node.

[konklone]

Yeah, we would go back and update the historical legislator file with a new ID. My proposal clearly jettisons history, so if it's a vital thing to keep, we'd need to have a separate file.

[konklone]

So I think we've proposed 3 solutions - let's pick one:

1. Keep a separate file that maps FEC IDs to people per-term
2. Store a top-level array of all FEC IDs that ever applied, and store an array on each term of all FEC IDs applied during that term
3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3 - since it seems like you could always answer the most common question (given this FEC ID, who does it refer to?) with that top level array. But you guys know the field better, so if you think #1 or #2 is worthwhile, we can do that, assuming you feel like doing the work to populate the extra fields and/or file.

[JoshData]

I vote #3!

• Josh Tauberer (@JoshData)

http://razor.occams.info

On 11/15/2012 06:07 PM, Eric Mill wrote:

So I think we've proposed 3 solutions - let's pick one:

1. Keep a separate file that maps FEC IDs to people per-term
2. Store a top-level array of all FEC IDs that ever applied, and store
   an array on each term of all FEC IDs applied during that term
3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3

• since it seems like you could always answer the most common question
  (given this FEC ID, who does it refer to?) with that top level array.
  But you guys know the field better, so if you think #1
  #1 or #2
  #2 is
  worthwhile, we can do that, assuming you feel like doing the work to
  populate the extra fields and/or file.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[dwillis]

I also vote #3.

[jsfenfen]

Don't have strong preference. Am officially voting "present".

On Fri, Nov 16, 2012 at 3:45 PM, Derek Willis [email protected]:

I also vote #3.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-10461521.

[konklone]

Done!

[konklone]

The commit:
4c5664e